Unless an organization deploys a single sign-on solution, its users will be required to remember multiple usernames and passwords, one for each different application in use. Additionally, the IT department needs to maintain all of these different accounts and passwords manually. Single sign-on allows users to sign in once with one account in order to access domain-joined devices, corporate resources, SAS applications, and even web apps. After signing in, users can then launch apps right from the O365 portal or via the MyApps access panel. With single sign-on, IT administrators can centralize user account management, allowing them to automatically add or remove user access to applications based on group membership. In this lecture, we are going to discuss the various single sign-on options that are available when designing an identity management solution that incorporates single sign-on. 

Choosing a single sign-on solution for an application will largely depend on how the application is configured for authentication. Of all the single sign-on methods we are about to discuss, disabled is the only one that does not automatically sign users into applications without requiring a second sign-on to occur. When deciding on a single sign-on solution, it's important to know that cloud apps can use SAML, password-based, linked, and disabled methods for single sign-on. Of the bunch, SAML is the most secure method. On-prem apps, when configured for Application Proxy, can use password-based, Integrated Windows Authentication, or IAW, header-based, linked, or the disabled methods for single sign-on. The table that you see on your screen provides a summary of the single sign-on methods that are available. Use SAML for single sign-on whenever possible. 

This method works when applications are configured to use a SAML protocol. Use password-based single sign-on when an application authenticates with a username and password. Using password-based single sign-on offers secure application password storage and replay via a web browser extension or via mobile application. Password-based single sign-on uses the existing sign-in process that's provided by the application while allowing an administrator to manage the passwords for it. The linked single sign-on method is useful when an application is configured for SSO in another identity provider service. This SSO option doesn't add single sign-on to the application. Use disabled single sign-on when an application isn't ready for single sign-on. Users of the application will need to provide their username and password each time they launch the application.

 Use IWA SSO for applications that use Integrated Windows Authentication or for claims-aware applications. When using this method for SSO, Application Proxy connectors use Kerberos Constrained Delegation to authenticate users to the application. Header-based single sign-on should be used when an application uses headers for authentication. It should be noted that header-based single sign-on requires PingAccess for Azure AD. When using header-based SSO, Application Proxy uses Azure AD to authenticate the user and then passes traffic through the connector service.