Authentication with Azure Active Directory

Outside of the standard deployment, there are federated options, and opportunities to provide secure access for partners and customers. Let’s have a look at how this all works…

How users authenticate with Azure AD

Azure Active Directory (AAD) is the directory that users authenticate with when they access any Office 365 service. While Azure AD can be a cloud-only service, most people have it linked to an on-premises Active Directory. This is synchronised using Azure AD Connect to make sure that all of the users and IDs are ready for use. As part of the standard deployment, this synchronises the users with Azure and can synchronise the user’s password (actually the hash of the password) to Azure, so that the same ID/password will work.

As the user wants to access the service they will enter the URL in a browser (outlook.office365.com) and they will be taken to the initial login web page. Here they are prompted to authenticate by the Azure service.

This will then check the ID and password against those that are stored in the Azure AD. If they are correct, the user will be signed in and get access to their service. In this case, the system shows the Outlook Web interface.

It is well worth remembering that this option is workable and can provide single sign-on with Windows 10 without the need for federation or any other software/hardware.

Federated Options

As an alternative to using ID and password against the Azure AD directly, the system can be set up to use a federated authentication. Here the user starts by going to the same page, but, as they authenticate, they are redirected to an on-premises server (running ADFS) for authentication. This happens when the user enters their ID and the domain is identified as one that is federated. With my OCG ID (this article was written prior to OCG UK rebranding to ThirdSpace, and then from ThirdSpace to Kocho), the authentication page looks like this:

In this case, the password does not need to be synchronised to Azure (it can still be synchronised, but it will not be used).

As an overall architecture this looks more like the following:

The ADFS box (in reality, an ADFS server would be hidden behind an ADFS proxy) responds to the authentication request and issues the relevant token to the user. This is then recognised by Azure and the user is allowed access.

The important element here is where the authentication takes place. With Password Sync and no federation in place, the user is authenticated against their own Azure AD. With federation, the user is authenticated by the on-premises ADFS against the local directory. This is always the case for the user.

Business to Business

With Business to Business links within Azure, a connection is created between your Azure AD and the identity held in your partner’s/customer’s Azure AD. As the user starts to access the service, they are identified by their ID and redirected to their own authentication source. This is outside of your Azure AD – all you need to know is that it is trusted. The external user then authenticates the way that they normally authenticate. This could be ID/password against Azure AD, or it could be using their ADFS. From your point of view, this is not a concern. All you need to worry about is that they do authenticate.

As the user tries to access the service they are prompted for their ID. If they are internal and federated, then they are redirected to the ADFS server. Otherwise they are authenticated directly against the Azure AD. Partners are identified and redirected to their Azure AD. If that is also federated, then they are redirected again (in the background) to their own ADFS server.

Business to Consumer

Many organisations want to bring their customers in to their services but without having to develop more internal directories. These customers may not access the system very often, so there may be issues with the users remembering their ID or password.

B2C gives you the opportunity to allow a user to sign in using an ID and password associated with your organisation and held in an Azure AD. Alternatively, you can link their Azure identity to their personal account in Amazon, Google+, LinkedIn or other services.

By using the Azure AD as the hub around all of this, the diagram shown earlier for partners can me modified to show alternatives. This diagram is simplistic but provides an overview for the service.

Here the user again starts by accessing the Application. To sign in, they are redirected to the Azure B2C system where they can authenticate. At this time, they can use their ID and password stored within the B2C directory or, if you choose to support them, they can use their social identity based on Amazon, Microsoft, LinkedIn, Google+ or Facebook.

By using a social provider, the user is more likely to remember their ID and password (they use it more often) so problems with authentication can be avoided as far as possible.

Conclusion

This is a very high-level look at how users authenticate with Azure-based services. However, the opportunities for businesses are clear. Moving beyond the standard deployment, and linking with external Azure ADs and social accounts, could help transform your relationships with partners and customers.