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 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:
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:
GET
for the page it wants to access.The NetScaler meanwhile saves the information about the GET
it received in its local state information to resume when the User returns.
/cgi/samlauth
appended to the path.
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:
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:
3.144.39.255