Single-sign-on (SSO) process and Methods
AZ-304 exam is retired. AZ-305 replacement is available.
In this, we will discuss and get knowledge about the process of Single sign-on (SSO) with understanding its methods and other important areas. So, let’s learn about this.
Process of Single Sign-on (SSO)
Single sign-on (SSO) provides security and convenience when users sign-on to applications in Azure Active Directory (Azure AD). With this, users need to sign in only once with one account for accessing domain-joined devices, company resources, software as a service (SaaS) applications, and web applications. And, after signing in, the user can even launch applications from the Office 365 portal or the Azure AD MyApps access panel. Moreover, the administrators have the ability to centralize user account management, and automatically add or remove user access to applications based on group membership.
Without single sign-on, users have to remember application-specific passwords and sign in to each application. Moreover, the IT staff needs to create and update user accounts for each application such as Office 365, Box, and Salesforce.
Choosing a single sign-on method
There are many ways for configuring an application for single sign-on. However, choosing a single sign-on method depends on the application configuration for authentication.
- Firstly, the cloud applications can use OpenID Connect, OAuth, SAML, password-based, linked, or disabled methods for single sign-on.
- And, On-premises applications can use password-based, Integrated Windows Authentication, header-based, linked, or disabled methods for single sign-on.
Types of SSO Methods
Below there are various single sign-on methods that can be useful.
OpenID Connect and OAuth
During the process of developing new applications, using modern protocols like OpenID Connect and OAuth can help in achieving the best single sign-on experience across multiple device platforms. Moreover, the OAuth enables users or admins to grant consent for protected resources like Microsoft Graph. In addition, it also provides easy to adopt SDKs for your app, and further, your app will be ready to use Microsoft Graph.
SAML SSO
Using SAML single sign-on, Azure AD authenticates the application with the user’s Azure AD account. Moreover, Azure AD communicates the sign-on information to the application through a connection protocol. SAML-based single sign-on also helps in mapping users to specific application roles based on rules you define in your SAML claims. However, SAML single sign-on is for applications that use any of these protocols:
- SAML 2.0
- WS-Federation
Password-based SSO
Using password-based sign-on, users sign on to the application with a username and password the first time they access it. After the first sign-on, Azure AD supplies the username and password to the application. However, the Password-based single sign-on uses the existing authentication process provided by the application. And, when you enable password single sign-on for an application, Azure AD collects and securely stores usernames and passwords for the application. The process of choosing a password type single sign-on is done:
- Firstly, when an application doesn’t support SAML single sign-on protocol.
- Secondly, when an application authenticates with a username and password instead of access tokens and headers.
Working of password-based SSO authentication
For authenticating a user to an application, Azure AD retrieves the user’s credentials from the directory and enters them into the application’s sign-on page. After that, Azure AD securely passes the user credentials via a web browser extension or mobile app. However, it doesn’t require users to remember their password.
Linked sign-on
Linked sign-on enables Azure AD for providing single sign-on to an application that is already configured for single sign-on in another service. However, the linked application can appear to end users in the Office 365 portal or Azure AD MyApps portal. Additional reporting is also available for linked applications that are launched from the Office 365 portal or the Azure AD MyApps portal.
Disabled SSO
Disabled mode means when a single sign-on is not in use for the application. However, when a single sign-on is disabled, users might need to authenticate twice. Firstly, users authenticate to Azure AD, and after that, they sign in to the application.
Use disabled single sign-on mode:
- Firstly, if you’re not ready to integrate this application with Azure AD single sign-on
- Secondly, if you’re testing other aspects of the application
- Lastly, as a layer of security to an on-premises application that doesn’t require users to authenticate. With disabled, the user needs to authenticate.
Integrated Windows Authentication (IWA) SSO
Application Proxy provides single sign-on (SSO) to applications that are using Integrated Windows Authentication (IWA), or claims-aware applications. However, if your application uses IWA, Application Proxy authenticates to the application by using Kerberos Constrained Delegation (KCD). For a claims-aware application that trusts Azure Active Directory, single sign-on works because the user was already authenticated by using Azure AD. Choose Integrated Windows Authentication single sign-on mode to provide single sign-on to an on-premises app that authenticates with IWA.
Working of single sign-on with KCD
The below diagram explains the flow when a user accesses an on-premises application that uses IWA.
- Firstly, the user enters the URL to access the on-premises application through Application Proxy.
- Secondly, Application Proxy redirects the request to Azure AD authentication services to pre-authenticate. And, here, Azure AD applies any applicable authentication and authorization policies, such as multi-factor authentication.
- After that, the user passes the token to the Application Proxy.
- Fourthly, Application Proxy validates the token and retrieves the User Principal Name (UPN) from the token.
- Then, the connector uses Kerberos Constrained Delegation (KCD) negotiation with the on-premises AD, impersonating the user to get a Kerberos token to the application.
- Here, Active Directory sends the Kerberos token for the application to the connector. And, the connector sends the original request to the application server, using the Kerberos token it received from AD.
- Lastly, the application sends the response to the connector, which then returns to the Application Proxy service, and finally to the user.
Header-based SSO
Header-based single sign-on works for applications that are using HTTP headers for authentication. However, this sign-on method uses a third-party authentication service called PingAccess. A user is only required to authenticate to Azure AD. Choose header-type single sign-on when Application Proxy and PingAccess configuration is done for the application.
Reference: Microsoft Documentation