As an Identity and Access Management (IAM) company, we constantly consider the impact of new and emerging trends on our customers’ business. Whether we like it or not, we are now in a new ‘post-PC’ world where we can no longer assume that organisations will depend on desktops to perform their business activities. Rather, more and more are pushing their staff, partners and customers towards smart apps on iPads, tablets and smartphones. Combined with social media and cloud computing, this raises many complex IAM challenges in areas such as fraud, authentication, management and theft.
So what can we expect? For one, Identity Governance is here to stay. Threats to business information and technology infrastructure haven’t gone away and, if anything, must now be even more carefully managed. Compliance is a constant and growing requirement. And controlling user access to sensitive data will remain a high priority. Organisations seeking to ensure their house is in order should consider an Identity Governance solution such as SailPoint’s IdentityIQ which, according to a new note from identity management analysts Kuppinger Cole, “should be included in any shortlist of platforms for Access Governance under evaluation.”
More interestingly and particularly challenging in this new era will be the requirement for adaptable methods for providing security such as authentication. OAuth is the default authentication method and a sound identity management strategy must entail careful consideration of how API interfaces make use of OAuth. Smaller organisations or point solutions might look at building OAuth support into applications. But this has ongoing support issues. OAuth is still emerging and you need to decide if we will build your apps using OAuth 1, OAuth 1a, or OAuth 2.0? What if you need to add HMAC support (digital signatures)? The standard is evolving very fast but so too are the security needs of your applications – especially as your enterprise apps mature, or you use third parties either directly or via a community group to build and extend them.
A significantly more flexible model would be the use of an API proxy, such as Layer 7’s API Proxy or its premium CloudConnect Gateway:
This technology enables you to ‘commoditise’ the security with out-of-the-box OAuth support. Simply by deploying the technology in front of your APIs you can start using OAuth. So if you’re building an application, or doing a COTS implementation, you don’t need to worry about security: once a user’s request is received, all the security is taken care of. Importantly, as your security needs advance, you can make all the necessary changes in a single place. Plus, it provides a method to provide backwards compatibility. Today, all your apps use OAuth 1.0a. Tomorrow, the risks change and you want to implement OAuth 2.0 with HMAC support. Most likely the implementation required by your risk department will be available in the API proxy. But if not, no need to worry, the technology is based on Java, so you can extend the existing capability to support your new needs. Once implemented, the challenge is then how to update all the apps. Not all users will update their apps on a regular basis. So you will need a way to accept the old authentication method until the users update their apps. Once again, this can be handled at the proxy layer in a standard way. Adding auditing will allow you to also see how many of the users have switched over.
- Commodisation of security into a proxy gives you flexibility
- Not all APIs are built securely
- Not all API interfaces are flexible
- OAuth protocol is emerging and constant changes are expected
- Always keep your users in mind. Just because you want to use the latest security fixes, does not mean the users are ready for them. Think of your users.