Among the most challenging aspects of Internet security is integrating disparate security systems while maintaining a seamless operation and safe environment. This is particularly important in e-commerce, where companies often need to exchange confidential data over the Web.
One initiative that the Organization for the Advancement of Structured Information Standards (OASIS) is overseeing is the Security Assertions Markup Language (SAML). SAML is an extension to XML, which deals specifically with the exchange of information between different security systems over the Internet.
What it is
SAML is not new technology; rather, it is a language that pulls together, into a single XML description, the information generated by different online security systems and allows them to communicate. Traditionally, IT security has been defined by the physical or logical boundaries of a single enterprise. But it’s becoming increasingly important for businesses to form online partnerships, which require shared, secure environments to run smoothly.
This is where SAML can help. It bridges the gap between traditional security boundaries and enables business sites to exchange security information. The result is that transactions initiated on one site can be completed at another trusted site, using SAML as the go-between. Commercial agreements/partnerships between businesses are a prerequisite to using SAML as part of a shared security infrastructure.
How it works
SAML works within the context of standard industry transport protocols, such as HTTP, SMTP, and FTP, as well as various XML document-exchange frameworks, such as SOAP and BizTalk. A key benefit is that SAML enables users to move across the Internet with their security credentials, which allows for a single sign-on using SAML as the intermediary language for authentication and access to shared resources.
SAML thus provides a common framework for the exchanges of authentication, authorization, and profile information across disparate, policy-based security systems. Because SAML describes existing security models through XML, it is also platform-neutral and independent of vendor architecture and/or infrastructure. The list below summarizes how SAML binds itself to commonly used transports:
Web browsers—SAML assertions are communicated by a Web browser through cookies or URL strings.
- HTTP—SAML assertions are conveyed from a source Web site to a destination Web site via headers or an HTTP POST.
- MIME—SAML assertions are packaged into a single MIME security package combined with the message payload (a purchase order, a bank’s line-of-credit statement, etc.).
- SOAP—SAML assertions are bound to the SOAP document’s envelope header to secure the payload.
- ebXML—This provides a MIME-based envelope structure used to bind SAML assertions to the business payload.
As you can see, SAML uses objects called assertions. These assertions are generated by and sent to trusted security authorities using a request/response protocol (SAMLQuery, SAML QueryResponse). SAML helps build a data format in XML for authentication assertions and authentication attributes, parameters used by security services to make authentication decisions based on policy.
SAML’s message format can push and/or pull assertions from an authoritative source to a receiver. This speeds up transaction processes and reduces the overall complexity of authentication environments in an e-business partnership. SAML does not build security policies—this is left to the relevant security authority, but it does provide the format for the expression of such policies so that security decisions can be made efficiently.
|A step-by-step look at how SAML works in its simplest form|
- User submits credentials to Authentication Authority (any security engine or business application that is SAML-aware).
- Authentication Authority asserts user’s credentials and generates an Authentication Assertion together with one or more Attribute Assertions (e.g., user profile information). User is now authenticated and identified by SAML assertions assembled in a token.
- User attempts to access a protected resource using the SAML token.
- Policy Enforcement Point (PEP) intercepts end-user request to protected resource and submits the end-user’s SAML token (Authentication Assertion) to the Attribute Authority (which can also be any SAML-aware security engine or business application).
- Attribute Authority or Policy Decision Point (PDP) makes a decision based on its policies. If it authorizes access to the resource, it generates an Attribute Assertion attached to the user’s SAML token. The end-user’s SAML token can be presented to trusted business partners in a single sign-on relationship.
How SAML can be used
Let’s take a look at some SAML usage scenarios.
In the simplest case, a user authenticates at a Web site but then needs to access resources on another related Web site. The destination Web site (the holder of secured resources) can use SAML to pull the user’s credentials from the source Web site. SAML processes happen in the background, so users are unlikely to know that their resources are actually located within a different security system.
Typically, when a user requests a dynamic protected/restricted Web resource, the request is passed to a back-end application. SAML interacts with the back-end security structures of partner organizations to determine whether they can grant access.
In this scenario, businesses participating in an online partnership can use SAML to permit their respective security structures to talk to one another so that transactions may be processed. Alternatively, the partners can use a trusted third party SAML B2B service, which acts as the focal point in the exchange of authentication and access to resources as required in the transaction process.
SAML can allow a user to travel freely between Web sites that are members of a single sign-on circle and retain session preferences and data across various resources that may exist on different sites. The source Web site acts as the credentials collector, and destination sites can pull required data as mentioned above. Again, the user is unlikely to be aware of the background security processes involved.
Becoming SAML savvy
Administrators need to be aware of what SAML can do. It is part of the oncoming wave of intersite operability, which promises to be one of the next big advances in Web functionality. In many cases, admins will need to oversee and implement intersite communications and become well versed in the security implications involved.