Ultimately, there comes a point in almost every application’s life where it needs to either protect resources, or access protected resources. This used to be solved by simple client-server authentication, where a resource owner (an end user who owns specific data hosted on a server) would exchange credentials with a server to gain access to protected resources.
However, with the advent and rapid development of distributed web services and cloud technologies, there grew an increasing need for third party applications to access resources on the user’s behalf. In order to do this, the resource owner would need to share their credentials with the third party. This poses several problems:
- The third-party service would need to store the user credentials to access protected resources, and there is nothing preventing the service from storing those credentials in plain text or other insecure ways.
- If a resource owner feels that their security has been compromised by a single third-party application, their only recourse is to revoke access to the third-party application in question, and consequentially all other integrated third-party applications, by changing their password.
- If a third party is compromised, the resource owner’s protected data is also compromised, potentially including their password. This could result in a user losing control over their account and all their protected data.
Essentially, this leaves users in a place where they need to absolutely trust that the application was not abusing or exposing their credentials in order to use integrated applications.
To mitigate this vulnerability, the Organization for the Advancement of Structured Information Standards (OASIS) came together in 2002 to draft SAML 1.0. SAML then underwent a minor revision in 2003 and landed on a final major revision in 2005 in SAML 2.0. Due to the deprecation of previous versions, further references to SAML in this article will be referencing SAML 2.0 specifically.
So, what exactly is SAML? SAML is a language specification based on the eXtensible Markup Language (XML). It defines what are called “assertions” that contain pieces of information about a user. The primary purpose this serves is to share information between disparate systems that have a trust relationship.
In the SAML protocol, there are essentially three players:
- The user - The end user that is a user of one or more protected applications.
- The Identity Provider (IdP) - The entity providing the identities of users and ability to authenticate a user. The IdP commonly will contain additional profile information about the user, such as their name, phone number, job title, etc.
- The Service Provider (SP) - This is an application that is serving protected resources belonging to or accessible by the user.
There are two general flows the SAML provides: service provider-initiated flow and identity provider-initiated flow.
In the IdP initiated flow, a user navigates to a site belonging to the IdP. The IdP then checks if the user has an established session – basically checking if the IdP already knows who the user is, typically by using browser cookies. If the user already has an established session, the IdP logs them in, typically redirecting them to a landing page with links to federated services. If not, the IdP prompts for authentication, normally a username and password. After logging in, if the user clicks a link to a SP site, the IdP generates a SAML assertion and redirects the user agent back to the SP, passing along the SAML assertion. The SP then validates the signature – a cryptographic key that was encoded using a private key belonging to the IdP – using the public certificate that pairs with the IdP’s private key used to encode the message. This ensures that the SAML assertion actually came from the IdP. Once the SP verifies that the information has came from the trusted IdP, they establish a security context with the user-agent and grants access to protected resources according to the user’s access level.
In the SP initiated flow, the user directly tries to access a protected resource in the service application via a user-agent (i.e. a browser). Not knowing who is trying to access the resource, the SP redirects the user-agent to the IdP. Here, the SP is asking the IdP, with whom they have established a trust relationship with, “Hey, do you know who this is?” The IdP then follows the login process, if the user does not already have an established session. Once the user is logged in, it again generates a SAML Assertion and (typically using the most common HTTP Redirect Binding), redirects the user to SP. From there, the steps match the IdP initiated flow.
What does this accomplish? Utilizing the SAML protocol protects users from sharing passwords between third party applications, as credentials are only stored by the IdP. If a third party is compromised, the IdP can choose to provide the ability to revoke access by disabling the configuration. While there isn’t a guarantee that the IdP itself isn’t storing credentials securely, IdP’s take care to maintain their users’ trust.
While SAML provides a more secure Single-Sign-On (SSO) solution, without Transport Layer Security (TLS), it remains vulnerable to man-in-the-middle attacks and eavesdropping. Another common attack exploited is a replay attack. If the SP can’t detect the replaying or reuse of assertions, they are left vulnerable to a replay attack, potentially exposing user data via a compromised assertion. Handling expirations and tracking unique identifier usage can protect against this vulnerability.
How are these limitations addressed? In the remainder of the series of posts, we’ll explore a newer authentication protocol, OAuth 2.0, that provides flexibility lacking in the SAML Protocol. OAuth 2.0 defines an easier way for application developers to ensure the security of their application, without providing workarounds for native and modern web applications.
 Cookies are small pieces of data, typically stored as key value pairs on a browser. They are normally used to maintain state. They can only be accessed by the same domain that created them. This means that a cookie from google.com cannot be accessed by the site at iseinc.biz.
 A trust relationship is essentially a business agreement between a SP and IdP in which the SP trusts the IdP to correctly identify users and provide accurate information about users.
 There are other bindings defined by SAML – HTTP Post Binding, HTTP Artifact Binding, SAML SOAP Binding, Reverse SOAP Binding, and SAML URI Binding -- but are out of scope of this article. See here for more detail.
Check back for future posts on easier ways to add secure authentications in web applications. Have questions? Contact us or join in the conversation below!