Hybrid Identity Management

calendar Sep 28, 2015 · 4 min read · microsoft windows azure active-directory  ·
Share on: linkedin copy

Last Thursday I spent the day with Microsoft in London finding out about their latest developments in mobile working strategy, data protection, and BYOD integration at an Enterprise Mobility Workshop.

I took pages of notes (OneNote was once again a winner) but the session I’m going to focus on in this post was around Hybrid Identity Management.

The Microsoft Hybrid Identity Management solution is (unsurprisingly) based around Active Directory and it’s cloud cousin Azure AD, and this is core to the entire Enterprise Mobility piece. The subject kept coming back in later sessions during the workshop- Azure AD was a real lynchpin of this whole day- and I got the impression that it’s vital that this is done right if any Mobility solution is going to work.

We’re living in a world of SaaS, IaaS, PaaS, anything as a Service. We have applications and services in the cloud, and “clouds are talking to clouds”. We have users on devices both on premises and out there in the big wide world. Identity Management is key to all of these issues, if everyone has a separate username and password for each service they use we find usernames and passwords recorded on Post-It notes so they can all be remembered. In addition, when a member of staff leaves, the organisation has to work hard to ensure that access to all those services is revoked.

Microsoft Azure Active Directory Premium offers “connectors” which enable other services- things such as Salesforce, WordPress, even Twitter, to use AD credentials. The user logs in to the 3rd party service in the same way they would to Office365. If an organisation has a specific service not on the list, there’s the interfaces and API’s available to allow a new connector to be developed. There is some variety in the “richness” of these connectors. As well as individual users being authenticated some of the connectors provide additional functionality- for example the Salesforce connector can actually provision new users within Salesforce based on AD Group membership.

The result of this integration is that IT can potentially provide “Single Sign On” (or at least “Same Sign On”) for all the services hosted both on-premises but also those cloud offerings- even Multi-factor authentication if that is required. The need for users to have secondary credentials for certain services and applications is reduced.

2-Factor Authentication, something I have (a key) and something I know (a number)

In addition there is Azure Active Directory Application Proxy. This is a feature whereby Azure is used to authenticate a user (again, including the option of 2FA) before they have access to an on-premises application. The user is approved before any traffic is allowed down the wire into the corporate network. Therefore, rather than the corporate firewall, local Active Directory, and the application server being responsible for guarding the gate and potentially susceptible to brute force and DoS attacks- this is all handled by the elastic and monitored cloud service.

If an organisation collaborates with external companies, and needs to grant them access to corporate resources, this can also be done using AAD. Traditionally this was done with an “internal” user account (which would naturally end up with more access than ideal) or an often clunky federated trust. Azure AD can work as a federation broker. You trust Azure AD, they trust Azure AD and you map the trust in Azure AD. If the external company doesn’t have an Azure AD setup then individual (and free) ad-hoc accounts can be created by them using a regular email address but either way you can specify granular access to your resources and revoke it when required.

With “Conditional Access Control” the service checks for more than just the identity of the user before granting access to resources. It also takes into account the authorisation strength- does a user need to login with 2FA to get access to that particular resource? It checks what device the user is on- is it known, managed, compliant, and not reported stolen? It checks what the business sensitivity of the application concerned is, and the location of the user. The whole point is to make sure that resources can only be accessed by the right person, in the right place, on the right device, and minimise the risk of business data being accessed incorrectly.

So there’s lots of features out there, not all of which need to be implemented on day 1 of a rollout, but without that solid Identity Management foundation, the pillars of Enterprise Mobility will be shaky from the start.