Nederlands
You have probably heard about it already: the use of Single Sign-On (SSO) is growing fast and millions of people worldwide already use it on their mobile phone. But what about companies and the SSO in their digital workspace? There is a distinction between Single Sign-On for the digital workspace and SSO for the applications within the digital workspace. In this blog, you will discover which methods you can use to make applications accessible in one click.
Federated Single Sign-On (SSO)
If you want to make an application accessible for Single Sign-On, you can choose from various authentication options. Authentication is the process of checking whether you are who you say you are. Federated SSO, a token-based SSO, is the safest method. These SSO solutions use the identity provider (IdP) of the organisation, such as Azure Active Directory (Azure AD). All your information is stored in the IdP, such as usernames, passwords, to which domains people have access, and also to which parts people have access within an application. For example, you may have access to view statistics, but not to edit them.
With federated SSO, several organisations have entered into a “federation” (cooperation) with each other. This means that those organisations use each other’s systems to authenticate people. It allows you to log in to different applications with the same account. This account is in fact trusted by the other organisations. Because of this, you do not have to create a new password for every application, because you link the application to an existing account.
Federated SSO methods
For SSO access to an application, it is useful to choose a SSO provider. Some well-known providers are Azure AD, Okta, NETIQ, HelloID and SecureLogin. They help you in delivering SSO to applications. These SSO providers often have a gallery with applications that they support. You can also add the applications of the above SSO providers to Workspace 365. This flowchart from Microsoft helps you determine the correct SSO method for your situation.
As can be seen in the flowchart there are many different SSO methods. A number of these serve as federated / token-based SSO. OAuth and SAML are the most used methods. The applications that are supported with OAuth or SAML can often be found in the gallery of the SSO provider. But how does the technology behind these methods work?
OAuth (Open Authorisation)
You probably recognise it: you want to log in to a website and you get the option to log in with an account from another website, such as Facebook or Microsoft. The other site, e.g. Facebook, arranges the authentication. The website that you visit logs in as soon as they have received permission via Facebook. In this situation, Facebook has a federation with the website where you want to log in.
Another example is that when you open your browser and log in to a website, the next time you open the same website or application through that browser, you will remain logged in automatically. This is because every time you open your browser, it gets an access token. Although this access token is only valid for a limited amount of time and you have to log in again when the access token is expired.
The underlying technology is OAuth and has the following advantages:
- An access token is used instead of a login code.
- The token exists for a limited time, a new token must always be requested.
- When changing or deleting an account, it is immediately effective when refreshing the token.
- The token is requested through a Client ID, this is provided once.
SAML (Security Assertion Markup Language)
SAML is a system that helps you gain access to applications that you need. It is the link between the identity provider and service provider. As a user, you log in once (SSO) to the identity provider (for example Azure AD) and then the identity provider can pass on all your information to the service provider when you try to access those services. The service provider checks with the identity provider whether you are who you say you are. Both systems communicate with SAML and therefore, as a user, you only have to log in once. Besides, SAML has the following benefits:
- You no longer have to remember multiple usernames and passwords.
- If someone leaves the company and you ensure that the employee can no longer log in to the IT environment within the company, this will also apply to all the connected cloud and web services.
- When people change their password, it also changes in the cloud and web services.
- With SAML you can keep track of logins for reporting in SQL (Structured Query Language) database or Active Directory.
What if my application is not supported by SAML or OAuth?
It may happen that you want to unlock a SSO application in your workspace, but it is not supported by the SAML or OAuth method and is also not listed in the application gallery of the SSO provider. You can then use the following method:
Password-based SSO
Password-based SSO gives the option to securely store an application password. A web browser extension then communicates this password to the application. This extends the login process of the application but gives admins the option to manage passwords, which can be an advantage.
A disadvantage of password-based SSO is that a plugin is required (from Azure AD for example). This plugin takes over the login fields such as username, password and the submit button, which allows the plugin in your browser to make (almost) all websites SSO. Even without having to make complicated links.
Using a plugin does not work on mobile devices, but luckily the SSO provider often has an alternative option for this. In case of Azure AD, you can use the Intune Managed Browser. This includes the plugin and you can also use Password Based SSO on mobile devices.
