SAML is an OASIS standard used to exchange authentication and authorization data between two parties. SAML uses an XML format to share information about who a user is and what they are allowed to do. Authorization data is included in a set of attributes provided in a SAML “assertion” (along with other identifying information); the assertion is generated by a trusted entity called the Identity Provider. An application that receives the assertion can then grant or deny access to resources based on the assertion attributes.
SAML 2.0 Terminology
- Identity Provider
- Service Provider
- Circle of Trust
SAML based Single Sign-On (SSO) works with systems hosted internally or externally and allows you to using the existing authentication system with your application. Authorization is still maintained within your remote application, so you can determine which users should have what level of access.
Overview of SAML Steps
- The user makes a request to a Service Provider for a specific resource. This request may happen in a variety of ways or reasons. For example, the user may be following a bookmark or clicking on a link from an email.
- The Service Provider detects that the user needs to authenticate and redirects them to the SAML Identity Provider. Along with a SAML Request, an HTTP parameter called RelayState is passed to the Identity Provider. This parameter captures the location of the resource the user originally requested.
- The user accesses their IDP and authenticates. This authentication is performed by the IDP giving the customer complete control over the authentication process. A variety of popular techniques may be used to authenticate; this includes basic authentication using an LDAP directory server, a web access management system, Integrated Windows Authentication, or a 2-factor system such as SecurID.
- Once authenticated, the IDP generates an assertion about the user indicating that they have successfully authenticated. The assertion is sent to the Service Provider. This response is relayed through the user’s browser, and includes the RelayState originally sent by the Service Provider. The echoing of RelayState is critical to the success of the protocol, as this is what allows the user to be returned to the originally requested resource.
- The Service Provider processes the SAML assertion and logs the user in. The digital signature included in the SAML assertion allows verification that the message is from the Identity Provider, at which point the user is authenticated. They are granted a session and redirected to their original request
Identity Provider performs user authentication and the underlying product after calling the Identity Provider performs the authorization. A goal of the central IAM system is to be similar to Identity Provider and authenticate customers globally (while the products manage authorizations locally). Some customers could act as the Identity Provider in this relationship and in fact, some Businesses already support this growing requirement. The central IAM system should also allow customers to act as Identity Providers, but rather than associating the user’s identity with a Business-specific account, their identity would be tied back to a centrally managed user identity that will be consistent across all Businesses.
Key advantages of SAML are:
Platform neutrality – SAML abstracts the security framework away from platform architectures and particular vendor implementations. Making security more independent of application logic is an important tenet of Service-Oriented Architecture.
Loose coupling of directories – SAML does not require user information to be maintained and synchronized between directories. (Although there are benefits associated with the creation of a common identity that cannot be experienced with loosely coupled identities.)
Improved online experience for end users – SAML enables single sign-on by allowing users to authenticate at an Identity Provider and then access Service Providers without additional authentication. In addition, identity federation (linking of multiple identities) through SAML allows for a better-customized user experience at each service while promoting privacy.
Reduced administrative costs for Service Providers – Using SAML to “reuse” a single act of authentication (such as logging in with a username and password) multiple times across multiple services can reduce the cost of maintaining account information. This burden is transferred to the Identity Provider. (This will reduce the complexity of our infrastructure and operating costs associated with managing and maintaining dozens of identity systems).
Risk transference – SAML can act to push responsibility for proper management of identities to the Identity Provider, which is more often compatible with its business model than that of a Service Provider.
Areas that SAML does not address are:
SAML does not require identities maintained by different Identity Providers be federated – only that the Service Providers trust the assertion created by the Identity Provider. Companies are often unable to obtain a corporate-wide view of a user’s activity across businesses, is unable to enforce corporate-wide security measures (such as authentication methods or security policies), and does nothing to move us towards a consolidated user directory for collaboration.
SAML DOES NOT help us move to a common interface for allowing customers to maintain their profile data. Customers may have multiple profiles both across products as well as within the products themselves (i.e. they may have multiple profiles in the same product created due to different relationships). Customers that end up having multiple profiles must maintain them separately – often across multiple product account management interfaces. Identities in the central IAM data store will consist of information that has been replicated from Business-specific Identity Providers; this will create a central identity about what we currently know about a customer and provide customers with a central interface they can use to update certain data.
While SAML allows multiple Identity Providers to coexist in the same environment, SAML DOES NOTHING to eliminate the multiple sets of credentials that a customer must maintain – oftentimes across multiple products. As products migrate, the IAM system will become the central Identify Provider for products. Customer will authenticate against the central IAM system using one set of credentials, the central IDP will then generate a product-specific assertion consisting of the data needed for the product to determine access, and the product will evaluate the customer data and grant or deny access accordingly.
SAML is not a complete solution. SAML DOES NOT, for instance work with non-Web based applications (Desktop applications).
Additional information on SAML: https://wiki.oasis-open.org/security/FrontPage
This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.
- Identity Federation Design Patterns: 1 – Executive Summary
- Identity Federation Design Patterns: 2 – Introduction
- Identity Federation Design Patterns: 3 – SAML
- Identity Federation Design Patterns: 4 – Open Authorization (“Oauth”)
- Identity Federation Design Patterns: 5 – Integration without IAM
- Identity Federation Design Patterns: 6 – Integration with a Central IAM
Also if you liked this blog then you might also like my previous blog “Benefits of Identity and Access Management as Corporate Service“