The latest version of JSCAPE MFT Server (8.8) already supports SAML Web SSO. Although we introduced SSO and its benefits in previous posts, we never went into the details of specific Web SSO standards like SAML and OpenID (also supported by 8.8). But in order to take advantage of any of our Web single sign-on features, you'll need to have at least some basic understanding of each of these two standards. Today, you can start with SAML.
What is SAML for?
One of the basic motivations for creating SAML was to overcome a common limitation of traditional browser cookie-based Web SSO technologies, who were only effective within a single domain. The moment an implementation required users to cross multiple domains (as is commonly practiced in large extranets), the solution was no longer straightforward. It required workarounds. Unfortunately, these workarounds entailed the use of proprietary mechanisms, which brings us to the main reason why SAML was developed.
As you may have gathered from the overview, SAML or Security Assertion Markup Language, is a set of standards for Web-based single sign-ons (SAML does have other use cases but Web SSO is its most popular). Why is it necessary to have a standard for Web SSO? You see, all those proprietary mechanisms were mostly incompatible with one another. The lack of interoperability between these solutions made it extremely difficult for two business partners who employed different SSO solutions to build a common single sign-on environment.
Because it is an open standard and platform-independent, SAML enables businesses to easily implement a common Web SSO for all its departments. It can even be used to establish a common Web SSO spanning multiple enterprises. As a matter of fact, it is in the enterprise space, where different companies using disparate IT systems interconnect through vast extranets, that SAML has gained widest adoption.
At the heart of SAML are four (4) key components: Assertions, Protocols, Bindings, and Profiles. The most fundamental of these, and the one we are most concerned of at this point, are the Assertions. Now you have an idea where the word "Assertion" in SAML comes from.
So what are SAML assertions?
Assertions are sets of information expressed in XML whose main elements are statements that assert (hence the term) something about an entity referred to as a "subject" or "principal". In most cases, the subject simply pertains to a user. So, for example, an assertion can state that: a certain user is named "John Doe", that his email address is "firstname.lastname@example.org", or that he authenticated with a trusted entity by submitting his username and password.
Statements can be one of three types: Authentication statements, Attribute statements, and Authorization Decision statements. Of the three, the Authentication statements are the most relevant in understanding SAML Web SSO and so is what we'd like to discuss futher.
During a SAML Web SSO session, an assertion bearing an Authentication statement is created immediately after a user authenticates. The assertion, which usually states what particular method was used to authenticate the user and when the authentication process was carried out, is issued by the entity that processed the authentication. That entity then forwards the assertion to a second entity who requires the assertion in order to perform a certain action, mostly to grant access to the user.
Let me take you through the basic SAML Web SSO process so you can see where this all fits in.
The SAML Web SSO process
A typical SAML Web SSO process consists of three main players: an Identity Provider (IdP), a Service Provider (SP), and a subject (the user).
✔ An Identity Provider is an entity where the user authenticates, i.e., where he submits login credentials. In other words, this is the entity who creates the authentication assertion and forwards the same to the second entity.
✔ A Service Provider is an entity providing some kind of service, e.g. secure file transfers. It is also the entity who receives the authentication assertion created by the IdP. A JSCAPE MFT Server deployment using SAML Web SSO is an example of a SP.
✔ a Subject is typically a user.
SAML Web SSO can be initiated by either the SP or the IdP. A Web SSO flow initiated by an Identity Provider is aptly called IdP-initiated, while a flow that begins at the Service Provider is called SP-initiated.
In IdP-initiated SSO, a user starts at the IdP. The IdP challenges the user to authenticate and presents him with a link(s) to one or more Service Providers (e.g. in the form of a menu) with which the user can later on access. After the user authenticates, the IdP creates an assertion about the authentication and sends the user off to the user's desired SP. When the user attempts to connect with a SP, he would be accompanied by that assertion. The SP in turn examines the assertion and then grants (or denies) access on the basis of that assertion.
An SP-initiated SSO is the exact opposite. A user first goes to a Service Provider and the SP redirects him to an IdP for authentication. Since SP-initiated SSO is the more common configuation, we'll dig deeper into the details of this particular flow.
1. First, the user arrives at the SP, presumably via a Web browser, to access the SP's services.
2. Since the user has not yet been authenticated, the SP creates a SAML authentication request and then redirects the user's browser to the IdP along with the authentication request.
3. Upon receiving the request, the IdP determines whether the user has an existing "logon security context", which in simple terms means, whether he has already logged on. If he has not, the IdP challenges the user to login and authenticate.
4. The user submits his valid login credentials and subsequently acquires a logon security context from the IdP.
5. The IdP now creates a SAML assertion that includes an authentication statement signifying the user's logon security context. It digitally signs the assertion and then sends that to the user's browser.
6. The user's browser forwards the digitally signed assertion to the SP, who then validates the digital signature, processes the contents of the assertion, and then (if all conditions are met) creates a "local" version of the user's logon security context. Once that is complete, the user will then be considered "logged on" at the SP and be able to access the SP's resources/services.
One thing I'd like to point out is that, in SAML (which differs from OpenID in this regard), there should be an existing trust relationship between the SP and the IdP. Although the latest version of SAML (2.0) now supports some kind of "IdP discovery feature" that's similar to OpenID, a large majority of existing SAML implementations are built on those pre-established trust relationships.
Thus, when the SP receives the authentication assertion in step 6 and recognizes the IdP who sent it, the SP immediately knows that the assertion (if it reflects a positive authentication) can likewise be trusted and that the user is legit.
Signing-on to multiple domains with a Federated Identity
So far, we've only discussed a user's sign-on to one service provider. But we all know that the beauty of single sign-on is that it allows users to sign-on once (with an IdP) and then enables them to have seamless access to multiple service providers. A vital component of the trust relationship we mentioned earlier is the concept of Identity Federation. That's what we're going to discuss before we end this post.
Whenever a user successfully acquires a logon security context at a service provider via Web SSO, it's assumed that the user already has a federated identity recognized by both the IdP and the SP. What this means is that the IdP and SP have previously agreed upon a set of identifiers/attributes which both entities will use to refer to the user.
This is important because it's always possible for a user to have existing local accounts on these providers and these accounts will likely have different local identifiers. For example, the user "John Doe" might be registered as "johndoe" on the IdP, "johnd" on SP1, "jdoe2014" on SP2, and so on. Since they all refer to the same user (John Doe), there should be a way to link them all or, in SAML jargon, establish a federated identity for John Doe.
In addition, how would an SP know that the John Doe account the user wants to access refers to the local account "JohnTheDoe" and not "JohnTheOtherDoe", especially since no local login will be taking place anymore?
There are a couple of ways to address these challenges. One way to establish federated identities is through out-of-band mechanisms like using X.509 subject names. Another way would be to share user information through off-line identity feeds coming from data sources at the IdP which would then be distributed to the SPs. Still another option would be to simply arrive at a business agreement allowing the identity provider to use certain attributes in referring to a user.
These methods are still being used in actual implementations and may suffice in most cases. However, if you want to take advantage of SAML messages to establish federated identities, you might want to look into the new features that come with SAML 2.0. SAML 2.0 offers a dynamic way of establishing federated identities. Let me describe how it works.
Let's use exactly the same scenario described earlier, i.e., user is John Doe, one IdP, and two SPs, etc. Let's also assume that, although John Doe has existing local identities (i.e., johndoe, johnd, jdoe2014) on each provider, he isn't logged-in locally to any of them and that he has no federated identity yet.
SAML 2.0 will dynamically establish a federated identity for John Doe following this procedure:
1. John Doe logs on at the IdP using his johndoe username.
2. After logging in, he sees the link to SP1 and decides to access its services. He clicks the link to connect. Upon connecting, SP1 sees that although John Doe isn't logged-in locally (and of course doesn't recognize him), he already logged-in at an IdP it trusts. SP1 then proceeds to ask John Doe if he wants to establish a federated identity between IdP and SP1.
3. If John Doe agrees, he is sent back to IdP, who in turn creates a pseudonym (e.g. ght45tu) that will be associated with the IdP local identifier, johndoe.
4. John Doe is then sent back to SP1, this time with a SAML assertion stating that pseudonym ght45tu has already logged in at IdP. John Doe will then be asked to log in using his local SP1 account johnd. This will then allow SP1 to determine which local account should be associated with pseudonym ght45tu. From this point onward, IdP's johndoe and SP1's johnd will be linked via ght45tu (see IdP and SP1 on the figure below).
5. The same procedure is applied for SP2. Notice, however, that the pseudonym IdP creates for SP2 (bgc45uy) is different from the one it created for SP1. Every time John Doe logs in at IdP, SAML Web SSO uses ght45tu to allow access for the johnd account at SP1 and bgc45uy to allow access for the jdoe2014 accountat SP2.
Having different pseudonyms for each IdP-SP pair while still referring to one user is actually a privacy-enabling feature of SAML 2.0. It prevents service providers from knowing which of its local accounts correlates with a particular local account in another service provider.
More about the security and privacy features of SAML in a future post. In the meantime, it's time for me to end this one.
For a more thorough, technical introduction to SAML, I recommend you read the SAML 2.0 Tech Overview from OASIS.
Highly Recommended Download
Remember that JSCAPE MFT Server already supports SAML 2.0. So if you're looking for a managed file transfer server that supports SAML Web SSO out of the box, try it now.