Speaking SAML

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".

Assert Yourself

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.Authorization assertions permit or deny access to specific resources--a file, device, Web page, specific database field or actions, like updating a list of phone numbers. The trade-off of, say, micromanaging access down to the field level of a database, of course, is that you have to develop and maintain a large security policy. But given recent regulations such as HIPAA (Health Insurance Portability and Accountability Act) and the Gramm-Leach-Bliley Act, this kind of detailed security management is a necessity in the financial, health-care and insurance industries.

SAML attribute assertions let you authorize users to access certain information in an application based on their "VIP-Status" or "Member_Level." (For more on assertions, see "The Three As").

SAML protocols define the format of requests and responses. All SAML exchanges, for instance, assume a trust relationship between the requestor--the application being requested--and the responder. Both parties must reference the same subject, so there's only one subject named "Bruce," for example, in the SecurityDomain "nwcinc.com."

Each request and response has a common header and is defined in a SAML document with the name space samlp. All SAML assertions are prefixed with the namespace saml, and each of the three types of assertions has a corresponding request protocol (see "Request and Response" at left).

Aside from the basic protocols, SAML also defines artifacts for browser redirection and single sign-on. An artifact is a pointer to a SAML assertion so that the application or Web server can retrieve the assertion. An artifact is small--less than 64 KB.

Bindings and ProfilesA binding is the method of transporting SAML requests and responses. The most widely used binding or transport for SAML is SOAP (Simple Object Access Protocol) over HTTP, but OASIS is working on a pure HTTP transport for SAML.

Profiles, meanwhile, describe things like where a SAML assertion can be found within a message. In SOAP, for example, the SAML assertion sits in the WSSE (Web Services Security Extension) header, which, in turn, is located within the SOAP header. To date, SAML comes with profiles for using it with Web browsers and SOAP.

There are two profiles for Web browsers: push and pull. In the push profile, HTML forms, including SAML assertions, are "pushed" to the destination via an HTTP post. In the pull profile, SAML artifacts are passed between sites as part of the URL query string. The big technical challenge with passing SAML assertions via the pull approach: The assertion is added to the query portion of the URL. Most browsers impose a limit on the size of a URL--Internet Explorer allows up to 2 KB--and some SAML assertions would be too large to fit within that window. SAML artifacts are a way to get around that problem.

The good news with SAML, meanwhile, is that the identity management server encapsulates and hides the actual authentication and authorization processes. That way, you can seamlessly mix and match security packages and apps from different vendors. So if you replace your LDAP server with an Active Directory server, the application server continues to process requests uninterrupted. And when two companies merge, for instance, they can keep running their own security systems with a SAML-based identity-management package exchanging security data between them.

So instead of getting locked into a specific authentication or authorization scheme, you can add a SAML-based identity-management system. It could save you from incompatibility headaches and having to recruit outside security integration experts.Lori MacVittie is a Network Computing technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].

Post a comment or question on this story.

How SAML Works

1. A user requests access to an application. He types in http://www.example.com/jobpostings.html

2. The application asks for his credentials. The user enters "John Smith" and his password, "h17&v5!"

3. The application sends a request to the identity management server for a SAML assertion with credentials. The application receives the user name and password, and then passes them to the identity-management server in the form of a SAML Request.4. The identity-management server queries the appropriate authentication server based on the preconfigured policies. This query is in the server's native protocol. The server queries an LDAP server to determine whether user John Smith exists and if his password is legitimate.

5. The identity-management server returns a SAML assertion to the application. Once that the server has confirmed John Smith exists and that he has properly identified himself with the correct password, it sends the application a SAML assertion stating that John Smith is authenticated.

6. Now it's up to the application. The application can allow access or create a SAML request for authorization (which means going back to Step 4). In this example, however, the application will determine whether John Smith is authorized to access "jobpostings.html."SAML was envisioned as a single sign-on method for Web browsing users. Around the same time in 1999, Microsoft introduced Passport, which was designed to enhance browsing between Microsoft and its partner sites. Liberty Alliance says it hopes to provide the same capabilities as Passport, but its specification has been written more with privacy - and end-user acceptance - in mind.

The latest version of the Liberty Alliance's federated identity specification provides an architecture for single sign-on using SAML (see "Making ID Management Manageable"). But the Liberty Alliance's implementation is fraught with difficulties. For example, the primary method of retrieving assertions involves browser redirection. Browser redirection increases traffic between the browser and multiple servers, and sessions and open connections proliferate, both on the desktop and the server.

That can lead to capacity overload on the server side and performance problems on the desktop.The Liberty Alliance's federated identity architecture provides multiple identities between two or more sites within a circle of trust, which is a group of businesses that have arranged to share customers. A third-party identity provider manages customer identities with single sign-on among the circle's sites and issues SAML assertions"all while protecting the customers' privacy.