{"id":1972,"date":"2020-06-18T03:44:07","date_gmt":"2020-06-18T10:44:07","guid":{"rendered":"https:\/\/www.sigcorp.com\/insights\/sig-supports-saml-2-0-single-sign-on-authentication\/"},"modified":"2020-06-18T03:44:07","modified_gmt":"2020-06-18T10:44:07","slug":"sig-supports-saml-2-0-single-sign-on-authentication","status":"publish","type":"post","link":"https:\/\/www.sigcorp.com\/insights\/sig-supports-saml-2-0-single-sign-on-authentication\/","title":{"rendered":"SIG Supports SAML 2.0 Single Sign-On Authentication"},"content":{"rendered":"\n

Security Assertion Markup Language (SAML) is an XML-based protocol that was developed to facilitate the exchange of authentication and authorization information between applications or entities.<\/p>\n\n\n\n

The protocol was created in November 2002 by an organization known as OASIS<\/a> (Organization for the Advancement of Structured Information Standards). OASIS still maintains the standard and the latest version of the protocol is SAML 2.0 (March 2005).<\/a><\/p>\n\n\n\n

The SAML specification has multiple versions and use cases. For this series I will focus on the latest revision, SAML 2.0, and the web browser based single sign-on (SSO) use case.<\/p>\n\n\n\n

Single sign-on (SSO)<\/a> refers to an experience where a user, or \u2018principal\u2019, can move between applications that do not share session information, without having to reauthenticate to each individual application.<\/p>\n\n\n\n

The framework provided by the SAML protocol is widely used to support a single sign-on (SSO) experience across web browser-based applications by integrating multiple applications with a common identity provider. The identity provider is responsible for maintaining a common user session\/context, allowing a user to move between applications without having to reauthenticate to each individual service.<\/p>\n\n\n\n

In addition to supporting a single sign-on experience between an institution\u2019s resources, the SAML protocol provides a framework for \u2018federated identity\u2019 that can be used to provide SSO between distinct organizations.<\/p>\n\n\n\n

The full SAML 2.0 specification can be downloaded from the OASIS website<\/a>.<\/p>\n\n\n\n

How Does it Work?<\/strong><\/h2>\n\n\n\n

SAML web SSO applications typically fall in to one of two roles:<\/p>\n\n\n\n

    \n
  1. Identity Providers (IdP)<\/u><\/strong> – The identity provider (IdP) is responsible for authenticating the user, establishing the SSO session and providing identity information to service providers.<\/li>\n\n\n\n
  2. Service Providers (SP)<\/u><\/strong> – The service provider (SP) is responsible for protecting its resources and relies on information from the IdP to establish a user\u2019s identity.<\/li>\n<\/ol>\n\n\n\n

    For example, an institution’s e-mail platform could be a service<\/a> provider with user e-mails representing the protected resource. Users are required to authenticate themselves to the IdP before they can access their mailbox.<\/p>\n\n\n

    \n
    \"\"<\/figure>\n<\/div>\n\n\n

    The IdP validates the user\u2019s identity by authenticating user credentials, which could take the form of a username\/password combination, an encrypted token, or some other method. The user authentication process is handled entirely by the IdP and is completely transparent to the SP. Once the user\u2019s identity is established, the IdP collects any additional user information the service might need and sends the user back to the SP.<\/p>\n\n\n\n

    Upon receiving an \u2018authentication success\u2019 response, the SP evaluates the authorization identity information from the IdP\u2019s response against its own internal access controls to determine what resources a user can access, if any.<\/p>\n\n\n\n

    It is possible for an application to function as both an IdP and an SP. This is common in an architecture where multiple IdPs are present and one IdP must delegate user authentication to another IdP that a trust has been established with.<\/p>\n\n\n\n

    Metadata<\/strong><\/h2>\n\n\n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n

    To establish the trust relationship between two entities, it is necessary to exchange some basic application information, such as application name, expected username format, supported protocols, endpoint URLs, etc.<\/p>\n\n\n\n

    This information is often collected into an XML-formatted document known as \u2018metadata.\u2019 The metadata document summarizes the application configuration details and describes how to interact with it.<\/p>\n\n\n\n

    Not all applications generate or consume metadata files. It may be necessary to create a service provider or identity provider metadata file for your application or it may be necessary to manually enter the values from a metadata file into a configuration file or administration console.<\/p>\n\n\n\n

    The format of the metadata document is governed by the SAML 2.0 metadata specification.<\/p>\n\n\n\n

    The full metadata specification can be downloaded from the OASIS website.<\/a><\/p>\n\n\n\n

    Assertions<\/strong><\/h2>\n\n\n\n

    The IdP and the SP applications communicate by exchanging XML-formatted messages that contain SAML 2.0 assertions. In web based SSO implementations, these messages are passed back and forth between the IdP and SP through the user\u2019s web browser. This is accomplished by encoding the message contents into a HTTP response and issuing a redirect (HTTP code 302) to the browser, as illustrated below.<\/p>\n\n\n

    \n
    \"\"<\/figure>\n<\/div>\n\n\n

    While there are multiple ways to initiate an SSO transaction in SAML 2.0, the most common is an SP-initiated authentication request. This occurs when a user attempts to access a SAML 2.0 protected resource without an existing SSO session. The SP generates an \u2018Authentication Request\u2019 assertion, encodes it in a message and forwards the user to the configured IdP to authenticate.<\/p>\n\n\n\n

    After authenticating the user, the IdP will generate an \u2018Authentication Response\u2019 assertion, encode the message and then redirect the user back to the SP with the assertion. The SP reads the assertion and determines whether the user should be permitted to access the requested resource.<\/p>\n\n\n\n

    Summary<\/strong><\/h2>\n\n\n\n