Reloading SAML: Do you really need SAML?
Recently I have been working closely and directly on Identity and Access Management (IAM) domain, which also raised a necessity to revisit most of the IAM concepts and standards again. As a person with a limited memory capacity I used to blog my studies/readings as much as possible, here is another attempt, this time on SAML.
Without any doubt I would say, SAML has been used by the vast majority of Internet users, it’s a different question whether they are aware that they have been using SAML or not.
Well, if I start with old school type question …
What is SAML ?
Everyone can easily find an answer from Wikipedia, but let’s leave that answer for a while and think about what conditions or what problems in our day to day life raise ‘the need’ to formalize such standard because without understanding such background any specification/standard is just a collection of technical jargon only, let me present you few stories ….
Story One
An airline called “MyAirways” operates their ticket booking and privilege club as two different business units, in order to reduce management overhead and to provide more efficient service. With this organizational structure, they have two separate web applications called “myairways.com” and “myprivilege.com” for each business unit.
Even though this sounds like a good business model for them, this set number of technical challenges. First, from the user's point of view, they access business offerings belong to one airline, the internal management structure is irrelevant for them. As you can imagine, asking users to maintain two set of usernames/passwords for each application or asking users to separately login at each application will seriously break the user experience.
At this point, someone can ask why can’t we use HTTP Cooke here to share logged-in contexts? According to HTTP protocol Cookies can not be shared among multiple domains, in simple words, a browser does not send cookies created for myairways.com domain when the same user accessing “myprivilege.com” domain. Top of this, synchronization of user stores connected to two applications also cause a lot of practical and security concerns, so we need to find a viable solution for this use case.
Story Two
Assume a new business partnership established between MyAirways and a leading hotel chain called HomeLike, with this new partnership those who book flights from myairways.com can get discounts from a web application called “homelike.com”. Additionally, regular customers of MyAirways can utilize their privilege club points to make payments on homelike.com. Once the business development teams came up with this win-win partnership, now it’s a challenge for technical teams to provide the right user experience. Compared to the previous story-one the technical complexity of this use case is much higher because practically it’s not possible to share or sync user stores belong to different companies due to many obvious reasons. Top of this some of the customers can have existing accounts on both applications, in such cases they may expect some sort of an association among existing accounts.
Story Three
Nowadays it is common to leverage cloud applications by enterprises over on-premise applications due to many advantages enabled by cloud applications. MyAirways also use a bunch of such cloud applications for internal purposes such as sales management, HR management, payroll management, expenses management etc.
But all of these cloud applications are manage and control by 3rd party companies, MyAirways only got paid subscriptions to use these applications. However in order for employees to use these applications, each employee needs to be provisioned on each and every application, and when they leave the job those people need to be de-provisioned from each application as well, this cause number of administrative issues. Additionally sharing internal employee data with 3rd parties increase great security risk as well.
So far we have shared three use cases without a proper solution ….
So what is the solution?
Single Sign-On (SSO) is the most prominent and widely accepted answer for the above discussed practical problems. Single Sign-On (SSO) facilitates to share the logged-in context of one application with a number of other applications via secure tokens and eliminate the requirement of re-login at each application.
Historically there was a number of protocols/ technologies developed to cater SSO use cases and some of them still use today, CAS is a good example. However, most of these protocols/ technologies developed their own proprietary protocols and it is required to deploy some sort of a proprietary agent/client within each and every application to communicate with SSO service.
SAML is the most successful attempt to standardize SSO technologies, it has been widely used during the last 10 years or so on. Additionally, there is a lot of supportive and interoperable specification developed around SAML ecosystem, as an example SAML can co-exist and collaborate with other identity protocols such as XACML and OAuth2. SAML also used as the base for new standards such as EU’s eIDAS standard for eID schemas.
How SAML differ from proprietary SSO technologies?
- SAML specifications are developed and maintained as open standards, this means anyone can review those specifications and figure out what really going on behind the scene, also anyone can contribute for further development of these standards as well.
- SAML use standard and highly interoperable text format called XML, any of the modern programing language can understand and process XML data easily, so any modern programing language can be used to generate or process SAML messages.
- Instead of developing own transport mechanisms SAML use existing Internet transport protocol such as HTTP and SOAP.
- SAML also use some concepts from widely used HTML standard as well.
Generic interactions among various roles involved in SAML standard can be summarized as follows.
- Generally, user profiles and user credentials are stored centrally within one system, this can be a homegrown system or can be an IAM solution.
- When a user tries to access a secured page/resource on an application it direct users to the central identity service via the user’s agent.
- The central identity service tries to authenticate the user and if it successfully creates a session for the authenticated user, then it creates a SAML token (XML message) and sends it back to the original application directly or indirectly (usually via user agent).
- This SAML token contains all the required identity data such as authentication method, authorization decisions, user attributes etc. The application uses this SAML token to create a local HTTP session and treat the user as logged-in.
- If the same user tries to access another application of the same organization, like in step-2 that application also redirects the user to central identity service.
- At the central identity service, it recognizes this user is already logged-in and skips the authentication steps. The central identity service generates a SAML token and shares with this 2nd application. Generally these 5th and 6th steps are transparent to end-users.
SAML is not limited to share identity details within the same organization or among partner organizations instead most of the cloud vendors such as AWS, Google, Salesforce support for SAML. Instead of duplicating user accounts in each of the cloud application, it’s possible to establish a trust relationship between cloud service and your own Identity Provider (IdP), with that model when someone tries to log-in to a particular cloud service it redirects the user to organizational IdP with a SAML request and expects SAML response back.
Here is the concrete example based on Salesforce.
I hope now you have a better idea about why identity experts have created such a standard called SAML and what problems it tries to solve, during the next post of this series I will try to discuss basics of SAML standard.
