- Web Service Collaborations
- Enter Single Sign-On!
- SAML (Security Assertion Markup Language)
- XACML
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
SAML (Security Assertion Markup Language)
SAML strives to provide a standard methodology to represent a principal's authentication and authorization information in XML format. This information can then be exchanged across intranets and the Internet. Thus, it enables sharing security and profile information across different segments involved in business (for example, customers, partners, and suppliers), regardless of their own enterprise security frameworks.
SAML is pioneered by OASIS, a non-profit organization for defining and promoting interoperable XML standards. It is a hybrid synthesis between two competing standards: AuthXML (from Securant/RSA to OASIS) and S2ML (from W3C and OASIS).
The SAML 1.0 specification set, released in Feb 2002, covers
Assertions: XML schema and definitions for exchanging security "assertions" across the services
Request/response protocol: XML schema and definitions for request/response model of transmitting security information
Bindings: specific SOAP calls over HTTP for transmitting SAML requests and responses
Profiles: for implanting and extracting SAML assertions
Security considerations: while using SAML
Conformance guidelines
A Test suite: use cases and requirements
In order to achieve single sign-on capability in Web services (which is what SAML is all about), the participating services should all be SAML-compliant.
Concept of Assertions
As the name suggests, the concept of assertions lies at the very root of SAML.
So, what is an assertion?
An assertion is a declaration of certain facts (statements) about a principal (subject). For example, an assertion can be made that a particular client was granted update and insert privileges to a specific database resource at a certain time.
The authority that issues assertions is known as the issuing authority. Applications and services, which trust the issuing authority and make use of its services, are called relying parties.
SAML makes use of the assertions concept to exchange security information across disparate systems and services. In a typical SAML cycle, the relying party, which needs to authenticate a specific client request, sends a SAML-based SOAP request to its issuing authority. The authority responds with a SAML assertion, which affirms the relying party with the security information requested.
There are mainly three kinds of assertions in the SAML realm. Regardless of their type, all SAML assertions include the following information:
Issuing authority and its timestamp
Assertion ID
Subject (Name + Security domain)
Terms and conditions against which the current assertion is valid (assertion validity timeframe, audience restriction, target restriction, and so on)
Additional "advice" (information on how the assertion was made, and so on)
Let's look at a typical SAML assertion with the above information, as shown in Figure 2.
)
Figure 2 SAML assertion with common elements.
Types of Assertions
The three major types of SAML assertion are
Authentication assertion. This assertion says that a specific subject was authenticated by the issuing authority at a given time. (Example: Subject A has been authenticated by means of methodology B at time C.)
Attribute assertion. This assertion describes specific attributes of a subject as name-value pairs. (Example: Subject A has been associated with attributes B, C, and D; and with values E, F, and H at the time of this assertion.)
A typical authentication assertion looks like the one shown in Figure 4.
Figure 4 SAML attribute assertion.Authorization decision assertion. This assertion says whether a given subject has been granted specific permissions to access a particular resource. (Example: Can subject A with evidence B be permitted to access resource C with privilege D at this time E?)
A typical authentication assertion looks like Figure 3.
)
Figure 3 SAML authentication assertion.
One interesting fact is that the SAML authentication assertion merely informs you about an act of authentication that took place at a given time! It does not define any specific requirements or specifications for the actual authentication methodologies deployed (such as username-password checks, and so on). As of SAML 1.0, password exchange, challenge-response, and so on are not within the scope of SAML.
)
Figure 4Let's look at a typical authorization decision assertion, as shown in Figure 5. (In all the preceding examples, please note that subject A can be an actual user or a Web service.)
)
Figure 5 SAML authorization decision assertion.
SAML does have the flexibility to extend this assertion framework and include custom-defined assertions based on the business need. But this comes at the cost of non-conformance to common and accepted standards.
If the issuing authority is hosted in a different domain, then the assertions can be digitally signed in order to ensure the authenticity of assertions. We will be looking at digital signatures later in this series.
SAML In Action
Let's look at the famous Producer—Consumer model of SAML interactions between the issuing authority and the relying party. (Have a look at Figure 6.)
)
Figure 6 SAML Producer—Consumer model.
The cycle is as follows: The end user credentials are collected from the system entity by a credential collector and passed on to the relevant SAML issuing authorities. The authorities issue appropriate assertions, based on the policies that bind them. The assertions are then assembled into an SAML token.
Not all client requests need to go through all of these authorities, and the coordination among different authorities is not mandatory.
During the actual application request to access a specific resource, the system entity has to append the corresponding SAML token issued by the authorities. The policy enforcement point intercepts the request, and submits the SAML token to relevant SAML authority to decide whether the request can succeed or not.
SAML—Protocol Bindings and Profiles
Bindings define the standard way that SAML request/response messages should be transported across the authorities and parties by providing mappings between SAML messages and standard communication protocols. For example, the way to map SAML with SOAP over HTTP protocols has been defined; this paves the way for exchanging SAML information across several Web services in a standard manner.
A profile describes how SAML assertions are embedded into and extracted out of standard frameworks and protocol. Web browser profiles for single sign-on and SOAP profiles for securing SOAP payloads are some of the profiles defined.
Future of SAML
Products and toolkits that support the SAML infrastructure have started arriving in the market. Netegrity's JSAML toolkit is one of the earliest entrants in the foray. Check out http://www.netegrity.com/products for details.
From the Java/J2EE side, the Java Community Process is working on two Java specification requests (JSR 115 and JSR 155), which are associated with SAML. JSR 155, which attempts to provide a standard Java API over Web service security assertion, is likely to become the standard for incorporating SAML into Java/J2EE applications.
Also, efforts are underway to define Web service standards for J2EE containers and components (Java enterprise Web services—JSR 109). In combination with JSR 115—meant for defining Java authorization service provider contracts for containers—this will result in standardization of authentication and authorization APIs within J2EE. On this basis, it is widely believed that in the near future, many J2EE vendors will adopt SAML as the standard means of exchanging security assertions between distributed components and runtime environments.
One of the biggest stumbling blocks for SAML's widespread recognition and adoption is its notable omission from WS-Security—a major Web service security framework initiative from Microsoft/IBM. For details, see http://www-106.ibm.com/developerworks/library/ws-secmap.
Unless these two major vendors support SAML in the near future, its usage may be seriously limited to the Java sphere.