|
|
|
|
|
by Jon Byous May 9, 2002 -- Vacation time is near, so you go online to make your travel arrangements, typing in your user name and password to log onto your Internet service provider. Done. You enter another user name and password to book a plane flight on your favorite travel web site. Done. Remembering that you need a car when you arrive, you sign on yet again to a rental agency's system. Your hotel reservation requires another fresh authentication. It's not just a matter of dealing with multiple vendors: Back from your vacation, you log in to your employer's virtual private network (VPN) with yet another user name and password. Then there's the HR system login to record your vacation time. And the finance system to approve an employee's travel expense report. And the payroll system to check your retirement account. Fortunately, multiple sign-on for secure authentication and authorization is quickly becoming a thing of the past for service providers who adopt the Security Assertions Markup Language (SAML) specification. In short, SAML enables open and interoperable designs for web-based single sign-on service functionality. Rima Patel, a Sun Technology Evangelist, provided an overview of SAML applied to single sign-on capabilities at the 2002 JavaOneSM Conference and in a follow-up interview. "Using SAML for single sign-on functionality allows users to authenticate themselves in one domain and use the resources in another domain without re-authenticating themselves," she said. The user's authentication, authorization, profiles, and preferences are transmitted from an original source service provider to subsequent destination service providers selected by the user during the session. Patel explained, "In many cases, the source and destination service providers will belong to the same 'federation.' For example, if you have signed on and been authenticated at the American Airlines domain and wish to rent a car, American Airlines will only share your sign-on information (and the associated password, profile, and preferences) with its contracted partners -- companies who enter agreements to protect secure shared information among themselves." SAML: Headed for Standardization"The idea of single sign-on services is not new, and versions have existed for several years," said Patel. "However, they are typically 'closed' solutions that don't offer broad interoperability. SAML, on the other hand, is a fully interoperable 'open' solution. There simply hasn't been a secure, interoperable standard for exchanging secure sign-on information, and SAML looks like it will be the first." "In addition," says Patel, "SAML is targeted as a security services implementation to support Internet2 and has already been approved or adopted in principle by a host of security and service providers." A sample of those providers includes:
The new SAML 1.0 specification is based on the merger of two formerly competing security efforts -- S2ML and AuthML. The SAML 1.0 specification set was released in February 2002, and the specification submission was provided to the Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org/ in March 2002 for standardization by the OASIS Security Services Technical Committee. (OASIS is a not-for-profit, global consortium that drives the development, convergence and adoption of e-business standards.) The related JavaTM technology API standard for SAML is in review at the Java Community ProcessSM (JCPSM) program http://www.jcp.org/ as a Java Specification Request -- JSR-155. What It IsSAML is an XML framework for exchanging security information over the internet. SAML enables disparate security services systems to interoperate. It resides within a system's security mechanisms to enable exchange of identity and entitlement with other services. "SAML does not define any new mechanisms or approaches to authentication or authorization," says Patel. "It does not, for instance, include requirements or specifications for the act of authentication or authorization." It does, however, define the structure of the documents that transport security information among services. By visiting http://www.oasis-open.org/committees/security/, you will see that SAML is a set of specification documents that define its components:
Assertions and Authorities"Assertions are at the very core of the SAML specification," says Patel. "An assertion is a declaration of a 'certain fact' about a subject, for example, a user or code." For example, that an individual was authenticated by a particular method at a specific time, or that an application has been granted a certain class of access to a resource under certain conditions. A SAML-compliant service, called a Relying Party, sends SAML Requests to an Issuing Authority, which returns SAML Assertion Responses. All of the requests and responses are transmitted within a SOAP envelope via HTTP, though Patel notes, "Your own applications can define and exchange assertions using a variety of request/response protocols, but those extensions may limit interoperability." For example, when a user signs into a SAML-compliant service, the service sends a "request for authentication assertion" to the issuing authority, stating that the user was authenticated by a particular method at a specific time. The issuing authority returns a "authentication assertion reference" that the service can pass to other sites so they can check the user's credentials. Later, when the user visits another SAML-compliant site that requires authentication, the site uses the reference to request authentication assertion from the issuing authority, which returns an "authentication assertion," stating that the user was, in fact, authenticated by a particular method at a specific time. Within the current specification, there are four types of assertions:
"Assertions do not create a secure authentication," explains Patel. That is the responsibility of the security service. Rather, "assertions are coded statements generated about events, such as authentication, that have already occurred," as, when the user provided a correct user name and password, or when the security mechanism granted specific permissions. Patel explained that assertions can only be generated and issued by a SAML "issuing authority." At present, there are two general types of issuing authorities. The first type includes third-party security service providers, such as:
The second type consists of individual businesses, such as AOL, American Express, and VISA, which can serve as issuing authorities within private federations by leveraging the Liberty Alliance technologies http://www.projectliberty.org/. "Using Liberty Alliance technologies, these issuing authorities can protect and 'own' their users while still sharing security information critical to access among many partners," adds Patel. Independent of the type of authority, when a user creates a SAML request through a service sign-on, assertions are generated by the issuing authority and transmitted within a SOAP envelope via HTTP.
Built on Simple, Common ElementsPatel explained that a typical SAML assertion consists of several common elements:
(See the Additional Links section below for the link to Rima Patel's complete slide set on the SAML architecture with XML code examples.) Good for Users, Good for BusinessPatel observed that today, many portal-based service providers offer "single sign-in" to the portal, but not "single sign-on," to multiple sites and services. "They are generally unable to provide full-strength single sign-on, which would include user profile and credit card information, across a federation of business partners" beyond the portal. She sees that problem disappearing quickly through the application of SAML. "There is no communication protocol for single sign-on right now," asserts Patel. "But using SAML, we can define that communication protocol, and believe me, a lot of service providers are interested in using SAML. It's in their best interest, even for Microsoft with their Passport service. Personally, as a user, if I have become used to the convenience of single sign-on for federations of cooperating service providers, and I come to Microsoft, and I can't have single sign-on, I would be annoyed." But of course, as Patel will admit, much has to happen before we reach that stage. "Each provider has to first make a business decision regarding single sign-on capabilities in association with their federation or business partners. Then they have to make a technology decision. As a technology, SAML is all about making single sign-on solutions interoperable among service providers," she says. "It is a very good solution that everyone can adopt."
See AlsoVisit the http://java.sun.com/javaone/ resources to download the 2002 JavaOne Conference session slides associated with this feature: Implementing Single Sign-on in Java Technology-Based Web Services (TS-2370), presented on March 29, 2002 by Rima Patel, Sun Technology Evangelist. SAML resources for developers are available through the OASIS http://www.oasis-open.org/ web site at http://www.oasis-open.org/committees/security/. A True Technology Evangelist Rima Patel is a Mathematics graduate (with some graduate-level studies) in Applied Mathematics from M.S. University (Gujarat, India). She has five years of industry experience, starting her career with training at an Indian computer institute. Prior to joining Sun as a Java Technology Evangelist, she worked as an Assistant Technical Architect responsible for designing network and application architecture for components and directories. Her technology interests include high performance networks, data server architectures and applied physics. She also loves watching sci-fi movies, reading sci-fi novels and thinking about sci-fi. |
|
|
|
