Single Sign-On and Multi-Factor Authentication
Last Updated: 16/06/2020
What is Single Sign-On and why do we need it?
Single Sign-On, which I will abbreviate to SSO for this post, is a type of identity-based access control intended for providing a user sign in with a single set of credentials to access a multitude of resources. As opposed to having to login with different credentials to each resource.
For example, we have an account for Facebook, Netflix, our Bank, and our mobile phone provider. Each of these have a different set of credentials (While you can use the same email address, the password will of course be different for each). This is because each of these have their own identity mechanism that operate independently. What if we could join all these together and access all of these services with just one username and password? That would be great right? We wouldn’t need to remember so many different passwords, this is what SSO is, but is of course more geared towards businesses.
SSO allows businesses to control and consolidate the identity management of various resources onto a single platform that gives a number of benefits. For one the user will only have to go to a single place to access all of their applications, likewise IT can control access and permissions to all of the applications behind the Single Sign-On system from one location. IT will no longer have to go to EACH application to provision user accounts and align permissions, this will all be controlled by the SSO system.
I have made a quick graphic (Need to work on my Visio skills) that shows what this would look like, as we can see the users logs into the SSO system which is connected to a number of different applications. These applications can be SAML 2.0 supported applications, or we can vault the credentials of web based applications.
Applications ideally should be SAML 2.0 supported to provide true SSO (more on this later) however some SSO providers allow the stuffing and vaulting of credentials to applications (the dirty method) which is handy for some applications that do not support SAML 2.0. We can also WS-Fed (Windows Server Federation Services) applications like Office365.
What is SAML 2.0 and how is this linked to SSO?
This is just a quick summary of what SAML 2.0 is and how it provides SSO. SAML 2.0 or Security Assertion Markup Language 2.0 is a language and protocol used for exchanging authentication and authorisation data between two identity systems. It allows one system to authenticate the user but then pass over a token to authenticate the user to the other system, without the user having to re-enter credentials.
For example: A user logs into an identity provider which has a SAML 2.0 connection to another application, the identity system will issue a token to the user which can be used on the other application the user wants to access. When the user attempts to access the application, the token is used which negates the need for the user to manually enter or re-enter credentials. In this example, authentication and authorisation has taken place on the first identity provider and the token issue allows access to the application that is governed by another identity provider. Please note that while this is similar to OAuth, SAML functions differently.
It should also be noted, if the user navigates straight to the target application/service provider and attempts to log in, the application will detect that the username used is from a SAML 2.0 federated account and pass it back to the Identity Provider/SSO solution. In short, authentication ALWAYS takes place on the Identity Provider of the user.
In the above graphic, if the user attempts to login directly to a 3rd party application that has been connected via SAML 2.0, the 3rd party app will detect the federated account and push the user to use the primary Identity Provider for authentication. This way, all authentication is taking place on the IDP of your choice.
Non-SAML 2.0 Applications
Not all cloud based applications are SAML 2.0 supported, in these cases we can use credential vaulting and use this to play back the password on a web form based system. Example below on how this would look:
The stored credentials can be specific to a user OR they can be shared credentials defined by IT, handy for controlling shared accounts and not revealing the password to the user needing access. Please note that this is not a preferred method of authentication, its dirty and effectively acts as a password vault, it doesn’t give a full or true SSO experience as there is STILL multiple identity providers/multiple credentials.
What does Single Sign-On look like for the users?
From a user perspective, we want the users to log in once with a known set of credentials (ideally their Active Directory credentials) to access all or at least most of their day to day resources. From this we can expect a user to access all applications from a web portal via HTTPS. The user will sign in and authenticate to the SSO provider. Here a list of applications will be presented, and credentials will not be requested when the user tries to access them.
For this example I am using Okta as the SSO provider and as you can see from the images below, I can sign in and see all of my applications. When I click on any of these applications, I will be able to access them without needing to input any additional credentials.
The user experience is that they will have A single place to access all of their applications and will only need to sign in and be challenged once in a set time period. Given that there is an increasing number of cloud and business applications, that likely require there own set of credentials, SSO helps users and can make there lives easier.
All of our applications are now in SSO, what’s next?
SSO is almost the first step in managing identity. Once we know that our users are authenticating at a single point (our SSO tool) then it makes sense to strengthen the security at this point, this is where we can start to introduce MFA.
By implementing MFA at this point, all applications in the SSO solution are now being MFA’ed, giving a consistent security layer over all applications.
As you can see from the above, we can now put an MFA challenge in place when a user authenticates to the SSO portal. All these applications are now protected with the same consistent security control. Although this can be scoped down further based on applications, location and device compliance.
Consistency is key, because a lot of cloud applications will support different MFA challenges (SMS, Email, Google Authenticator, Microsoft Authentication ect.) so, by consolidating the MFA challenge in the SSO solution enables users to use a default MFA method, rather than have 3 different applications to authenticate into a number of different applications (which can quickly become confusing). So the two benefits here is: the same consistent security among supported applications and ease for the user for authenticating.
How do I Control who is MFA’ed?
First we need to look at what we want to control, we want to control which users who are in certain locations, on certain devices, access applications and if they need to be challenged to gain access. If we simply MFA everyone regardless of location, device and application, then MFA is only going to cause friction. So we need to take into account the users location, the device context and the application they are attempting to access and determine if they should be challenged, allowed to access with one authentication factor or simply denied access altogether. Similar to the below:
So how do we acomplish this? Well, we can implement Conditional Based Policies for authentication. A simple example could be: If the user is in a certain IP address range or Country, then they will not be able to access certain applications or stop authentication all together. For example, we could write the following rules:
- If you are inside the Corporate IP Address range, then do NOT MFA.
- The justification here is, if the user has got into the building, past reception, through the doors that required a pass card, plugged in and received an IP Address, then username and password should be fine.
- If you are outside the Corporate IP Address range but in the UK, then MFA.
- User could be working remotely, at home or at an airport. Let’s challenge them with MFA just to be on the safe side.
- If the user is attempting to authentication from outside of the UK, then block authentication.
- User could be attempting to read there emails on holiday, or it could be a bad actor. Let’s not take chances and block access from countries where we do not have a presence.
These are just basic example and can be customised further, these can also be scoped by user and application, as well as adding in device context (ie. Does the user have a corporate device?). A good example of this is: HR can only access the HR system while in the Corporate IP address range and on a domain joined/compliant device, and will also be challenged with MFA. Should HR be working from home or remotely, then they will not be able to gain access to the HR System. There are a number of different ways that this can be configured dependent on the protection required.
Does having SSO mean introducing another Identity Provider?
Most SSO solutions are their own Identity provider, the diagrams I crudely drew up on Visio shows it as a separate entity. However, most SSO solutions will allow connections to various other identity providers, such as Active Directory. This will synchronise the users accounts across to the SSO provider, negating the need to duplicate or recreate users. Because of the synchronisation this means that a user can be created in one place and pushed to the other. This process is generally agent based. Okta which I used in my examples, uses the ‘Okta Active Directory Agent‘ which needs to be installed on a member server, whereas Microsoft used the ‘AD Connect Tool‘, which is again deployed on a member server on the domain.
Why are IT managing users? Lets give the responsibility to HR
To further the above section, some SSO solutions like Okta can connect into HR systems and pull the user data in. This is handy for creating a workflow for starters, leavers and movers. When HR onboard a new employee into the system, this will push the user information into Okta, Okta can then kick off a workflow to provision a user account and give access to the relevant applications. Ie. If the user is in sales then the user would have access to Email, CRM and an Expenses Application with certain rights and roles (assuming the applications support this type of user provisioning). Once the user account is pushed from the HR system and into Okta, Okta can then write this back down to the Local Active Directory via the Sync. This can alleviate some of the admin overhead involved in the Starters, Leavers and Movers process, but also help align the HR System with AD ensuring that user information on both is up to date (As opposed to having an active user in AD that has left the company months ago!)
Wrap up and Summary
There is quite a bit of information in this post, in order to summarise here are the key points for SSO:
- A single place for users to authenticate and access their applications
- A single place for IT to manage access for users and gain access to audit reports of what users have accessed and when
- A chance to provide MFA for all supported applications with a consistent approach to security, whilst defining and dictating the rules of authentication of each user and application they need to access.
- Consolidation of identity providers by using the SSO Solution as the primary identity provider which connects into HR Systems and Local AD.
- For true SSO then SAML 2.0 will need to be supported. SAML 2.0 is generally used with enterprise based applications, where as OAuth is more web/public applications.
There are a number of Identity solutions that provide SSO as part of their service, each provider will have have slight differences and advanced features. Here are the two identity providers I have worked with that provide SSO:
- Okta – Leader in Identity according to Gartner, provides SSO and MFA functionality in addition to a number of other identity services. I find Okta easy to administrate and deploy, as well as having a very modular approach allowing you to roll out different functionality when needed. Okta also has strong B2C functionality which makes it my first choice in the identity space in regards to functionality and usability.
- Azure Active Directory Premium – Great identity tool that compliments and extends out the standard Azure Active Directory included with Office365. Easy to deploy if you have already moved users into O365/Azure AD. SSO and MFA functionality come as part of the Azure AD P1 feature set which can be accessed via EM&S E3. Azure ADP makes sense to consider as a strategic option if you are planning to consume a number of features from the EM&S stack.
Again, there are many options out there for identity, SSO and MFA. It makes sense to consider a number of different vendors and solutions depending on your requirements.
Credit to Giuseppe Damiano for reviewing and suggesting a number of changes.