A secret handshake or an inside joke.
Fun ways for us to share information to each other, secretly. Without the historical association, others will fail to get access or understand the full meaning.
Welcome to SAML
SAML is a way to securely share authentication and authorization information between two parties. Most often, SAML is used to provide single sign-on to SaaS applications.
In order to work together, SAML uses 3 main components:
- Identity Provider (IdP): The IdP is the source of truth. It is the entity that is able to prove the person is who they say they are
- Service Provider (SP): The SP is the resource the user is trying to access. Often, the SP is a SaaS application
- Assertion: The assertion is a statement of fact, most often sent from the IdP to the SP. The assertion provides information about an authenticated user.
How these things fit is as follows:
SAML isn’t creating a single account across multiple services, it instead associates accounts. In a SAML architecture, the SP trusts the IdP. If the IdP asserts that someone is who they say they are, the SP trusts it.
In order for SAML to work, both parties (the IdP and the SP) must have a common attribute that associates two accounts. This common attribute is included within the assertion.
What becomes really interesting with SAML, is that you can have a situation where the user does not know their user account information in the SP. The user account in the SP might also not have a password. The SP can force authentication to always happen via SAML.
Think about what this means. The only way for a user to access the SP is to go through the IdP.
- Easy to disable access to all apps for a user because you only have to disable one account – the identity provider account.
- Eliminate the threat of weak passwords on SaaS apps because there is no password
- Improve authentication security by adding strong authentication to the IdP. Based on the nature of SAML, strong authentication for the IdP = strong authentication for the SP.
In order to get SAML to work, the IdP and SP must talk to each other in a certain way. Oftentimes, this comes down to a few configuration specifics:
- Assertion URL: The Identity Provider must know about the Service Provider’s SAML URL. This will be slightly different than the URL for the Service Provider’s app. Instead of company.SomeApp.com, the Assertion URL might be company.SomeApp.com/includes/saml
- Issuer URL: The Service Provider must know about the Identity Provider’s URL that is issuing SAML assertions.
- Attribute: The Identity Provider uses the attribute to know what information to include within the assertion sent to the service provider. The attribute is the common thread that associates the service provider’s account with the identity provider’s account.
- Certificate: The Identity Provider provides the Service Provider with a certificate, which the service provider uses to encrypt data sent to the Identity Provider.
- Relay State (optional): Once the SAML authentication completes, the Identity Provider uses the Relay State to redirect the user to a specific URL.
With SAML, there are two ways users can access a service.
- IdP-Initiated – In an Identity Provider initiated flow, the user first authenticates at the IdP. From the IdP, the user then accesses the service. In the realm of Citrix, you can think of a user accessing a SaaS app Citrix Workspace as an IdP-initiated flow.
- SP-Initiated – In a Service Provider-Initiated flow, the user first attempts to access the service. The service provider forwards the request to the identity provider to authenticate the user. Once authenticated, the IdP sends the assertion to the service provider. SP-Initiated is often how most users access a resource, which is most likely via a browser’s bookmark.
Looking at an Assertion
I recently ran into an issue setting up SAML authentication where the process was failing. Doing a SP-Initiated flow, the SP redirected the user to the IdP correctly. The user authenticated to the IdP. However, when the user was redirected back to the SP, the process failed.
Based on the SAML flow, the issue was either an incorrect Relay State or the Assertion was not correct. In this instance, I knew there was no need to use the Relay State, so I was left with a problem in the assertion.
How can I even look into the contents of an assertion?
The good news is that it is extremely easy: Browser Developer Tools!
Once the SAML Chrome Panel is available, you can hit F12 to load the developer tools. This adds a new tab in the developer tools specifically designed for SAML.
When you access a SAML authentication flow, you can see the assertion getting sent from the IdP to the SP. Inside the assertion, you can see all of the attribute names getting sent as well as the associated values.
In the issue I had with my SAML configuration, it turns out that the parameter “cip_sid” was incorrect. I actually needed to set my attribute on the SP side to be “http://schemas.auth0.com/cip_sid”.