SAML offers a standards-based approach to implementing single sign-on (SSO) and authentication across multiple applications and services
A basic SAML implementation will consist of a client, a Service Provider (SP) and an Identity Provider (IdP). The diagram below shows the communication flows between the entities.
With a SAML environment, all user authentication can be delivered from the IdP giving a single point to manage the user identity lifecycle, to log session activity and to consistently apply policy across applications. Polices can be used to control many user and session attributes such as minimum password length and inactivity timeouts. Routine maintenance tasks such as password resets and user provisioning/de-provisioning are greatly simplified with a single point of administration.
With password re-use across SaaS services being a widespread user behaviour, the security of user credentials is only as strong as the weakest link. Most SaaS platforms (such as SalesForce and Office365) can federate with corporate SAML environments so that no user login credentials are stored in the cloud and password policies can be centrally enforced.
The proliferation of applications and services means that users have to remember multiple credentials. This can lead to poor practices such as the writing down of passwords (or even worse storing them) and reusing the same password across multiple services. Implementing SAML based single sign-on makes life easier for the user (only one set of credentials to remember, only sign in once) and reduces helpdesk workloads (fewer password related issues).
LoadMaster acts as a Service Provider (SP) in a SAML environment. As an SP, LoadMaster redirects client access requests to the IdP for authentication where the client will receive a SAML assertion that will be presented to the LoadMaster. The LoadMaster accepts the SAML assertion and grants access to the service.
The following diagram shows an example of a LoadMaster being used to offer SSO to multiple services. The IdP in this example is Microsoft AD FS and the application workloads consist of an internal corporate portal with no authentication, Microsoft Exchange Outlook Web Access and Microsoft Sharepoint. LoadMaster leverage Kerberos Constrained Delegation (KCD) to provide authenticated clients with access to AD based services.