SAML 1.1 is an XML framework developed by OASIS (Organization for the Advancement of Structured Information Standards). It's used for Web single sign-on in the Liberty Alliance specification 1.1 as well as for authentication services in the alliance's Web Services Security specification. (For more on the Liberty Alliance spec, see "Give Me Liberty?"
and "Making ID Management Manageable"
.) Web services are emerging as a hot spot for SAML: Provisioning packages such as Novell's Nsure and Computer Associates' eTrust Admin soon will support SAML. Meanwhile, key software vendors, including CrossLogix, IBM's Tivoli Systems, Netegrity, Novell, Oblix, RSA Security and Sun Microsystems, offer support for SAML in their security applications. And Microsoft's new .Net Server operating system will come with SAML support, too (for more on Web Services Security, see "Dive Carefully"
SAML, which is platform-independent, consists of assertions, protocols, bindings and profiles. Assertions are statements that an identity authority makes about an end user--human or machine. An identity authority is a trusted source of authentication and authorization decisions, such as Active Directory. AD serves as an identity authority in many organizations because it typically contains security information for multiple applications. Assertions are a response to requests like "Is John Smith allowed access to the HR Web site?"
There are three types of assertions: authorization, authentication and attribute. All assertions include a set of common elements: the subject, conditions and authentication statement (see "The Table of Elements," left).
Each assertion also contains information about the type of request made. If a user requests authorization to a human resources application, for instance, the assertion says whether he was allowed or denied the request, and the scope of the his privileges. If he requests authentication to the network or an application, the assertion specifies the method of authentication and the date and time he was authenticated. This lets the application determine whether the authentication method the user went through is sufficient. Some applications, like e-mail and e-commerce, accept a password, while a health-care record application requires something stronger, such as a security token. The application can accept or reject the authentication assertion. SAML can use passwords, Kerberos, secure remote passwords, hardware tokens, public keys (X.509, SPKI, XKMS, SSL/TLS certificates) and XML digital signatures.