Security Assertion Markup Language (SAML) is an XML based AAA mechanism which is starting to take off as a prominent way of doing web-based SSO between different enterprises (or partners). The main reason for its success is that it takes away the complexity of handling authentication from the enterprises that actually provide the service. This advantage is especially amplified in the case of multi-tenanted environments and means that the two different environments can evolve at their own speeds.
SAML, conceptually, has three entities:
- The User with their browser.
- A Service Provider (SP), who is responsible for providing the resource, such as a web page.
- An Identity Provider (IDP), who is responsible for confirming to the SP that a User is who they say they are and, when needed, providing additional attributes about the User that the SP can then use to make a decision on granting access to the service. The messaging units (formatted in XML) used to present this information are called assertions.
The glue that holds this model together is the trust between the SP and the IDP. That trust uses a couple of concepts that we'll discuss briefly: Certificates and Canonicalization.
SAML's distributed model crosses enterprise boundaries. So, having a way to trust messages between the parties responsible for the service – the NetScaler, the IDP, and the SP, is key.
X.509 certificates were the model chosen to establish this trust, as the certificate model had already proved itself in the Internet world. The NetScaler, IDP, and SP each encrypt and sign their messages using their public keys. Thus it is important that the CA certificates (whether they are self-signed or signed by a public CA) are trusted by the receiving parties.
Canonicalization is an XML signatures concept. Two XML documents can be physically different (for example, when viewed on an editor), and yet be semantically the same. This poses a challenge for mechanisms such as SAML, which rely on XML signatures for message validation. The problem originates from the fact that when the two physically different messages are encrypted and signed, the resulting signature hashes will be different. Thus the validation will fail at the verifying party and as a result the SSO will fail.
Canonicalization is a technique where the signing party generates a second version of the message, called the canonicalized version. This is done using techniques and algorithms followed by the various parties for compatibility. The canonicalized version only cares about specific parts of the message that are important, and not the entirety. Once signed this way, the receiving party, who also knows how to create a canonicalized version, does so before calculating the digest for validation.
The troubleshooting section lists some counters that help identify SSO failures resulting from certificate or message validation failures.
Depending on the deployment choice, there are two possible flows for SSO:
- SP Initiated SSO
- IDP Initiated SSO
Let's look at what these are and the associated flows.
Here, the SSO process is initiated by NetScaler. The LB vServer acts as the Service Provider associated AAA vServer acting as the SP.
Please check out Citrix blog 174193098 for an example of how to set this up; it will serve as a handy base deployment using just a free IDP, a NetScaler, and any regular web server. Now let's look at the flow to expect when using such a deployment:
Something to remember when looking at traces is that there is no communication between the NetScaler and the IDP here. There is an implicit trust between the two parties, achieved through the binding of appropriate certificates.
The following Wireshark screenshot shows what the exchange looks like between the User and the NetScaler VIP:
Let's deconstruct the steps:
- The client sends a
GETfor the page it wants to access. - Since there are no AAA cookies in that request, NetScaler realizes that this is an unauthenticated User and instead of responding with the requested page, responds with a form script, which, when executed on the User's browser, redirects them to the IDP SSO URL to authenticate:
The NetScaler meanwhile saves the information about the
GETit received in its local state information to resume when the User returns. - The User, as a result of step 2, does a POST to the IDP at the SSO URL, this POST also includes the referer and origin headers:
- The User gets prompted for credentials.
- The User provides credentials and gets authenticated.
- This will result in another form script (similar to the one from NetScaler earlier), which will provide the User the assertion and where to POST that assertion. This script is saying to the User: "go back to the SP and provide this assertion to get access to your resource":
- The User will POST the assertion to LB VIP, with
/cgi/samlauthappended to the path. - This will result in a redirect once again to the LB VIP, but this time with the all essential AAA cookies that prove the User is authenticated:
- The User now acts on this redirect and asks for the same resource as in step 1, but with the cookies.
- The NetScaler, having verified the cookies, returns the requested resource.
In the case of IDP initiated SSO, the User, instead of going to the resource (SP) first, lands on the IDP at a URL configured for SSO.
The User doesn't need to know how to create this URL by themselves. It will be provided to them as a result of accessing a simpler landing page – such as a web-based CRM, embedded with this URL, crafted for SSO. This URL will contain a couple of important parameters:
- The SP's identity
- The URL that the User is actually trying to get to, via the RelayState parameter:
Flow for IDP initiated Auth
In the following example I am using a simple web page with an embedded URL to simulate an IDP initiated scenario. Here, unlike with the SP initiated scenario, the User learns of the SP via the IDP. The following fiddler trace shows the full exchange from the perspective of the User's machine:
Fiddler trace taken on Client for IDP initiated Authentication