SAML

exchange authentication and authorization data


18 Feb 2017 View Comments
#saml #markup #security #authentication #authorization #SSO #computer

We talked about OAuth last time, SAML has often discussed along with OAuth. They are kind of related yet have the different purposes. SAML’s focus is on the Authentication whereas OAuth has its focus on Authorization. SAML tries to provide the service with one ID (identity-as-a-service). Security Assertion Markup Language (SAML) is an open standard for exchanging authorization and authentication information between domains using standardized XML. SAML is brought to us by OASIS’s security service technical committee for handling SSO issues. SAML Profile with Redirect/POST bindings is one of the most common SSO (Single Sign On) implementation. SSO did not have many problems within the intranet. However, it required an SSO standard that works over the full internet. Keep in mind both OAuth and SAML is a concept/framework.

Unified ID

We had days when the network wasn’t even setup/connected and we authenticated through the actual device or system which had the id and key information stored to validate. Then we were introduced to the network/the internet. Things were still the same, we would punch in username and password to the system that we are trying to gain access. However, there were many cons for doing this. For example, we had to keep username/password for each system. Also, it was fairly responsible for the system administrators spent countless hours trying to update/delete the username/password when someone leaves the company. Things were even uglier when there was a severe security measure. With an introduction to the SSO, we only had to manage username/password in one place.

Single Sign On (SSO)

In the beginning of World Wide Web, websites were very simple and static. And SSO (Single Sign On) used to be treated as a redundant extra idea then. However, as the internet evolved along with WWW, things became much more complex. It is common for an identity to host multiple websites. It’d be much hassle to login for each website just because they are in different locations. SAML is a very important standard for this to happen. I would say this is the key concept of the “authentication”.

Design

SAML is built upon a number of existing standards:

  • Extensible Markup Language (XML)
    Most SAML exchanges are expressed in a standardized dialect of XML, which is the root for the name SAML (Security Assertion Markup Language).
  • XML Schema (XSD)
    SAML assertions and protocols are specified (in part) using XML Schema.
  • XML Signature
    Both SAML 1.1 and SAML 2.0 use digital signatures (based on the XML Signature standard) for authentication and message integrity.
  • XML Encryption
    Using XML Encryption, SAML 2.0 provides elements for encrypted name identifiers, encrypted attributes, and encrypted assertions (SAML 1.1 does not have encryption capabilities). XML Encryption is reported to have severe security concerns.
  • Hypertext Transfer Protocol (HTTP)
    SAML relies heavily on HTTP as its communications protocol.
  • SOAP
    SAML specifies the use of SOAP, specifically SOAP 1.1.

Use case

The primary SAML use case is called Web Browser Single Sign-On (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML identity provider through the user agent. The resulting protocol flow is depicted in the following diagram:

Single sign-on using SAML in a Web browser
Single sign-on using SAML in a Web browser
  1. Request the target resource at the Service Provider (SAML 2.0 only)
    The principal (via an HTTP user agent) requests a target resource at the service provider: https://sp.example.com/myresource. The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.
  2. Redirect to the SSO Service at the IdP (SAML 2.0 only)
    The service provider determines the user’s preferred identity provider (by unspecified means) and redirects the user agent to the SSO Service at the identity provider: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request. The value of the SAMLRequest parameter is the Base64 encoding of a deflated element.
  3. Request the SSO Service at the IdP (SAML 2.0 only)
    The user agent issues a GET request to the SSO service at the identity provider where the value of the SAMLRequest parameter is taken from the URL query string at step 2. The SSO service processes the AuthnRequest and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
  4. Respond with an XHTML form
    The SSO service validates the request and responds with a document containing an XHTML form:
      <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
        <input type="hidden" name="SAMLResponse" value="response" />
        ...
        <input type="submit" value="Submit" />
      </form>
    The value of the SAMLResponse parameter is the base64 encoding of a <samlp:Response> element.
  5. Request the Assertion Consumer Service at the SP
    The user agent issues a POST request to the assertion consumer service at the service provider. The value of the SAMLResponse parameter is taken from the XHTML form at step 4.
  6. Redirect to the target resource
    The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
  7. Request the target resource at the SP again
    The user agent requests the target resource at the service provider (again): https://sp.example.com/myresource
  8. Respond with requested resource
    Since a security context exists, the service provider returns the resource to the user agent.

Table of comparison between OAuth and SAML

  OAuth2 SAML
Token (or assertion) format JSON or SAML2 XML
Authorization? Yes Yes
Authentication? Pseudo-authentication Yes
Year created 2005 2001
Current version OAuth2 SAML 2.0
Security Risks Phishing HTTP Redirect (GET) binding
  OAuth 2.0 does not support signature SAML SOAP binding
  encryption HTTP POST binding
  channel binding XML Signature Wrapping to
  channel binding impersonate any user
  client verification.  
  It relies completely on TLS for confidentiality.  
Transport HTTP HTTP
Best suited for API authorization Single Sign On
Share this post

Me

I am a passionate software developer working in Downtown, Vancouver. I strongly believe in art of algorithms and together with it to write clean and efficient software to build awesome products. If you would like to connect with me, choose one from below options :) You can also send me an email at