Since a few years a lot of applications are being offered as a service in the cloud. This Software as a Service model has become very popular because it provides more flexibility without worrying about configuring and maintaining the infrastructure and platform where the application runs. More and more companies are starting to make use of this type of services. Sometimes the employees are already using it and the IT organisation is not even aware of it. Some good examples in this case are Dropbox or OneDrive which are frequently used by employees at home. On the other hand, even when the IT organisation is aware of the usage of cloud applications or maybe they even introduced them; How can you be in control of for example access and how can you provide a Single Sign On experience for your employees as they have with their on-premises applications?
The answer to this question is pretty simple. Traditionally, in the on-premises situations a single Identity Provider is already configured to provide Single Sign On to on-premises applications and to provide a way of Access Control. After logging in to your workstation you can simply make use of any (Kerberos) application without authenticating every single time you access different applications. Active Directory Domain Services is widely used for these purposes and in some cases the Active Directory Federation Services is added to provide access to an internal application from the internet.
To provide this same experience we have to extend this Identity Provider role to the cloud and connect the different cloud application on to it. Microsoft offers Azure AD as THE platform to realize all of this. Of course Kerberos is not used in this case but protocols like SAML, WS-Federation, OpenID and Oauth are used to create trust relationships between Azure AD and SaaS applications. This will not only just provide a single account which can access multiple applications without logging in but it will also provide an company, insights in who has accessed what application, at what time and from what location. I will come back on this aspect in later post, where I will elaborate on the report functionality.
The big advantage of using Azure AD is the pre-configured applications which Microsoft has added to an Application Gallery. In this gallery you can find various of applications which you can simply add to your Azure AD configuration.
For this applications, Microsoft has already configured most part of the trust relationship with a SaaS provider. In most cases you only need to finish the configuration by uploading some information about your Azure AD tenant within the SaaS application properties.
I will now go over the configuration of a test scenario to get an idea on how you can add an SaaS application to your Azure AD tenant and how users are able to access multiple applications based on Single Sign On. In the example I will make use of the New Relic application as my SaaS application.
In the application tab in your Azure AD tenant click on ADD and select Add an application from the gallery:
Now search for the application New Relic and add it to your configuration:
A new screen will open up which will let you choose what type of Sign-On experience you prefer. At this moment Azure AD offers 3 options:
– Windows Azure AD Single Sign-On, this option will configure a trust relationship between Azure AD and in this case New Relic.
– Password Single Sign-On, by using this option, you have to login in to your SaaS application once to save the credentials in Azure AD. The next time you will experience a “Single Sign On” experience.
– Existing Single Sign-On, this third option can be used to create a link to an application which is configured to authenticate using Active Directory Federation Services.
In this case we choose for the Window Azure AD Single Sign-On option because this gives us the ability to make use of the same Azure AD user account within the application. In case you have an SaaS application in use with a lot of users and you do not want to provide your users with new application accounts, you can either choose for Password Single Sign-On.
On the next screen we fill in the login URL of the application. Which in case of New Relic is:
We first download the certificate and log in to our New Relic subscription. Open up the Account Settings page and click on Single Sign On:
In the SAML Identity Provider certificate entry you can now upload the just downloaded certificate.
Next fill in the SAML identity provider details as provided in the Azure AD configuration window.
And we are done! Just click on Save my changes and test the configuration by logging in with an Azure AD account.
After enabling SSO you can Assign Users who can access the application and you will be able to access the New Relic application by using the Azure AD portal or fill in your Azure AD account on the New Relic Sign in page and you will directed to Azure AD authentication page.
By adding more and more applications to your Azure AD tenant you are able to let users log on to the different applications with just a single account. By combining this and my ealier post on synchronisation identities to the cloud, you are creating a hybrid identity which is able to log on to on-premises applications and cloud applications all with a Single Sign On experience. I think that’s pretty awesome!