What is SAML?
Security Assertion Markup Language (SAML) is a computer protocol that allows users to reuse their authentication credentials to log into multiple applications, instead of setting up new accounts with new credentials for every application. SAML is not the only protocol that does this. OpenID Connect (ODIC), for example, is a very popular authentication protocol for consumer applications that allow users to use their Facebook or Google accounts to log into other Web applications instead of setting up new accounts for every application. SAML does the exact same thing only using different technical conventions. From the users’ perspective, they do the same thing.
Let’s look at an example:
Your company developed a new HR application that allows employees to request time off and track their salary and benefits. The app is accessible through hr.mycompany.com. Because the application deals with personal data, it requires users to authenticate. The developer could have implemented a user authentication module for the application that would register new users, manage their access credentials, authenticate them, and revoke their credentials when they leave the company. Instead, the developer chose to rely on an existing authentication infrastructure already operational at the company. Now, all the developer has to do is implement SAML authentication to allow the HR app to rely on authentications performed by the company’s central authentication server.
With SAML implemented, when a user connects to the application, the HR application responds with a “note” to the company’s authentication server (located at auth.mycompany.net) asking it to authenticate the user, and redirects the user to the authentication server. The authentication server authenticates the user, creates another “note” stating that the user has been successfully authenticated, and redirects the user back to the HR application. If the user was already authenticated, then the authentication server automatically redirects the user back to the HR application with the authentication “note”, without asking the user to authenticate again. The HR application checks the authenticity of the authentication note and lets the user in.
The note-exchange is all transparent to the user – it is performed by the client application used to access the HR application – typically a web browser – the HR application and the authentication server. The notes themselves are formatted as XML messages.
In SAML jargon, the authentication server is called the Identity Provider or IdP, and the HR Application is called the Service Provider or SP.
Benefits of SAML Authentication
Better User Experience — users sign in once to the Identity Provider (IdP) and can access any application that works with that IdP. Authentication works like a single sign-on.
Improved Security — authentication is implemented by the IdP instead of each application building its own authentication capability, which is likely to be flawed and buggy thus open to attacks.
Easier and more cost-effective to maintain — user identities are maintained in one location instead of being replicated multiple times in multiple user directories.
Now let’s formalize things and see how SAML might be set up with the Octopus Authentication Server.
Security Assertion Markup Language – SAML – is an XML-based open-standard for transferring authentication and authorization data between two parties: an identity provider (IdP) and a service provider (SP). The IdP maintains user accounts and identities and performs authentication. The SP is any application that delegates the job of authenticating users to an IdP which it trusts.
The Octopus Authentication Server operates as a SAML Identity Provider (IdP) and the HR Application in the example above is the Service Provider (SP) that delegates the job of authenticating users to the Octopus Authentication Server:
- Users attempting to access the HR App from a web browser.
- HR App generates a SAML authentication request and responds with it to the browser.
- The browser redirects to the IdP and passes along the authentication request.
- IdP parses the authentication request and authenticates the user. If the user is already/recently authenticated, then it skips re-authenticating the user, generates a cryptographically signed response, and responds with it to the browser.
- The browser redirects again, this time back to the HR App, and sends the authentication server response it received.
- The HR App looks at the response and validates its integrity. If everything checks out, the user is given access to the app.