Skip to Content Sun Java Solaris Communities My SDN Account Join SDN

SDN Home > Identity Management > Reference > Technical Articles & Tips >

Article

Federated Identity: Single Sign-On Among Enterprises

Print-friendly Version

By Pat Patterson, Pirasenna Velandai Thiyagarajan, and Marina Sum, October 14, 2004

The ubiquity of the Internet has made numerous applications available online to the general public, from banking to investment to shopping to paying bills to playing music. You name the task and a Web application is at your service. The single most important security safeguard for those tasks is the authentication of the user's identity. That is, the service provider must ensure that the person who's performing those tasks is the authorized user, not an imposter. That's where user IDs and passwords come into play as credentials to prove identity and as a prerequisite for authorized access to applications.

Within an enterprise, Single Sign-On (SSO) for all its applications in one login pass makes logistical and economic sense. Better yet, you can go a step further: implement federated identity and extend SSO across enterprises, thus reaping even more convenience and time savings for both organizations and users alike.

This article outlines the background and process of achieving federated identity with Sun Java System Access Manager (called Access Manager for short). This theme is also the subject of a Webinar on developers.sun.com held on October 5, 2004.

Contents

-	Persistent Logins Across Applications
-	Basics of Web-Based Access Control and SSO
-	Federated Identity
-	Selected Q&As From Webinar
-	References
-	About the Authors

Persistent Logins Across Applications

Consider this scenario: You want to find a coworker's phone number in the corporate white pages on the Web and then call him. Your IT department has determined that the white pages contain sensitive information and has implemented access control there. Therefore, before you can look up that phone number, you must first log in to the white pages with your user ID and password.

After calling your coworker, you'd like to access a widget supplier's site from a link on your corporate portal, both access control--protected. Not only must you log in to the portal, you must also do so at the supplier site. In the course of a day, you might find yourself logging in to a dozen different applications. More cumbersome yet, you might have to define and remember a different set of credentials for each application because credential requirements vary, for example, how many characters minimum must be in a password, whether they must be a mixture of alphanumerics, and so forth.

Now consider an alternative: You log in to the white pages. From there, you can browse the corporate portal and then order widgets on the supplier's site throughout the day--all without more logins. Moreover, each application recognizes you and grants you access according to your role within the organization. Your supplier's portal can even tell your location so that you need not type in a shipping address for your widget order.

Sounds like magic? Not really, just access control, SSO, and federation at work:

Access control ensures that only authorized users can access the protected resources.
SSO minimizes the number of user logins.
Federation extends access control and SSO across organizational boundaries.

Basics of Web-Based Access Control and SSO

How does Access Manager provide access control and SSO to applications? FIGURE 1 illustrates the workflow.

FIGURE 1 Workflow for SSO

Here's a summary of the process:

The Security Angle

Given that the SSO token travels back and forth in a browser cookie, how do we ensure security? Three techniques can mitigate security risks:

You can restrict the window during which a session can be compromised. That is, sessions have a limited lifetime, after which the user must reauthenticate. You can set that lifetime limit on a per-policy basis and thus balance the inconvenience of reauthenticating against the criticality of the resource.
You can encrypt the SSO token to protect it against eavesdropping on the wire. All Access Manager components are enabled for channel security through the Secure Sockets Layer (SSL) and Transaction Layer Security (TLS) protocols.
You can configure Access Manager to issue a unique SSO token for each protected resource. Subsequently, no rogue programs can harvest tokens for use across the network.

The user attempts to access a protected application on a Web browser.
A policy agent installed on the Web server or application server intercepts the access and checks for a valid SSO token, which is typically presented as a cookie. You can deploy policy agents to a range of Web servers, application servers, and even enterprise applications from vendors such as Lotus, SAP, and Siebel.
The policy agent redirects the user's browser to a login page and earmarks the URL originally requested by the user as a parameter.
The user authenticates to Access Manager, typically by typing in a user ID and an associated password. A browser certificate, a smart card, and other similar devices are alternative means of authentication; the user might access an application through one of those devices instead of through a password. Afterwards, Access Manager creates a session with a specific lifetime. For the duration of that session, the user is signed on according to the policies that are in place.
Access Manager sends the user's browser a cookie that contains an SSO token and redirects the browser to the originally requested URL. Afterwards, the user's browser repeats the request in step 1, this time with the token-included cookie.
The policy agent finds the cookie, extracts the SSO token, and validates it with Access Manager.

If Access Manager's policies have granted the user access to the requested application, the user can proceed. Otherwise, the policy agent denies the request with either an HTTP error or a redirect to a page with an "access denied" message.

Subsequent requests for other protected applications will include the SSO token. Again, the Policy Agent validates the SSO token and the user's authorization and then allows or denies the request, as in step 6.

This sequence of events can repeat until the user's session expires or until the user explicitly logs out.

Federated Identity

The SSO mechanism functions well within the enterprise. However, a crucial disadvantage is its dependency on browser cookies, which are limited by design to a single Internet domain only.

Federated identity accords access control and SSO across departmental and enterprise boundaries. The advantages are many:

Establishment of trusted partnerships, that is, tighter, more satisfying customer and employee relationships
Extended and new revenue opportunities
Generation of new, efficient, and productive business models

A critical component for the implementation of federated identity is the Security Assertion Markup Language (SAML), an XML framework for exchanging data. SAML is managed by the Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS). The Liberty Alliance Project builds on SAML to deliver more extensive federated identity.

SAML

The current version of SAML is 1.1, with 2.0 in the works. SAML enables cross-domain SSO by defining the following:

A set of XML elements that represent identity information (attributes that describe the user), with the assertion being the key element
A pair of profiles (protocols)--the Browser Artifact and the Browser-POST--that use Simple Object Access Protocol (SOAP) and HTTP to exchange identity information

The two profiles allow an asserting party (also called a SAML producer) to send identity information to a relying party (also called a SAML consumer) so that the latter can provide service. In the scenario described in "Persistent Logins Across Applications," the asserting party is your employer and the relying party, the widget supplier. Your employer sends along your identity information, including your shipping address, so that you can order widgets without having to authenticate at the supplier's site.

The two profiles are similar in nature. The major difference is that, instead of using a "back-channel" SOAP-HTTP request to transmit assertions between parties, the Browser-POST profile does so with a form post. For details on the profiles, visit the OASIS site.

SSO Workflow

FIGURE 2 illustrates the SSO workflow for the Browser-Artifact profile.

FIGURE 2 SSO Workflow for the Browser-Artifact Profile

Here's a summary of the process:

The Security Angle

The Browser-Artifact profile relies on a back channel between the two providers, so the service provider can count on the channel security protocols (SSL and TLS) for confidentiality, integrity, and authentication.

The Browser-POST profile relies on the identity provider to send the assertion to the service provider through a form post. The identity provider must sign (and optionally encrypt) the assertion to guarantee security.

At the start of the day, the user authenticates at the asserting party's site--a protected intranet--in the normal way.
Some time later, the user clicks a link on the intranet to access the relying party's site.
The link actually directs the user's browser to a service on the asserting party's site. This service creates and associates an artifact and an assertion so that it can retrieve the assertion later. The artifact comprises a 20-byte source identifier and a 20-byte random handle. The service then constructs a target URL that contains the artifact.
Access Manager redirects the user's browser to the relying party's site, from which the user's browser then requests the target URL. This URL contains the SAML artifact as an HTTP parameter.
The relying party sends the artifact to the asserting party in a SAML SOAP request over HTTP.
The asserting party looks up the assertion (created in step 3) with the artifact and sends the assertion to the relying party.

The relying party now has the assertion, which contains the user's identity, and can then serve content slated for the user.

A key benefit of this federated approach is that since it trusts the accuracy of the identity information from the asserting party, the relying party simply acts on that data and need not maintain a separate identity repository.

You can deploy Access Manager as the SAML producer at an asserting party. Relying parties can use Access Manager's Software Development Kit (SDK) to easily implement a SAML relying party.

Let's examine a couple of code samples in the next section and learn how a Java servlet uses the Access Manager SDK to retrieve user identity data through the SAML Browser-Artifact profile.

APIs and Code Samples

Here's a recap of the two roles in SAML interactions:

SAML asserting party -- This is the identity provider (IDP) with the authority to make assertion statements about users. Users authenticate according to the manner mandated by the IDP.
SAML relying party -- This is the application that provides service to users and that relies on the IDP for authentication assertions.

FIGURE 3 illustrates the SAML roles and interactions. SAML assertions are generated in site A and consumed in site B.

FIGURE 3 SAML Roles and Interactions

Like the roles, the SAML APIs are divided into two categories:

SAML Assertion Producer APIs -- You must use these APIs along with a session management and authentication framework. That framework must be present for a SAML asserting party to validate identities, express constraints, and issue valid assertions. Access Manager's SAML Producer API implementation manages its artifact and assertion information relevant to its sessions. That way, you can use the Access Manager SAML Server APIs to create services deployed on the same servlet container as Access Manager.

CODE EXAMPLE 1 demonstrates how you can use SAML Assertion Producer APIs.

import javax.servlet.*;
import javax.servlet.http.*;
import com.sun.identity.saml.SAMLClient;
import com.sun.identity.saml.common.SAMLException;
import com.sun.identity.saml.assertion.Assertion;


/**
 * Your service class that will run on the same servlet container
 * instance as Access Manager.
 *
 * Before accessing this servlet, the user must have authenticated with
 * Access Manager.
 *
 * In a real development scenario, the servlet must check for and validate
 * the cookie. If cookie is absent or invalid, the servlet must send
 * failure status.
 */
public class TestSAMLSerice extends HttpServlet {
    public static final String ARTIFACT_ATTRIBUTE = "artifact";
    public static final String ARTIFACT_TARGET =
    "http://col.snowborn.com/SAMLReceiver";

    public void doGet(HttpServletRequest req,
                      HttpServletResponse resp) throws ServletException {
        try {
            /**
             * This API will get the user's session token and the session
             * properties from Identity Session cache, then generate an
             * artifact for the target.
             */
            assertion = SAMLClient.doWebArtifact(req, resp,
                                                    ARTIFACT_TARGET);
        } catch(Exception samlEx) {
            throw new ServletException("Error while generating artifact.",
                                      samlEx);
        }
     }

CODE EXAMPLE 1

SAML Assertion Consumer APIs -- In a SAML SSO, site A must know site B's URL, to which it can send Browser-POST and Browser-Artifact profiles, mostly through a secure channel. For each site, only a few public URLs are available to handle SAML interactions. Applications are loosely coupled and depend on those edge components to help with SAML interactions, offering scalability as the number of applications increases. Certain deployment scenarios may warrant tighter integration with the SAML API, however. The two code examples in this section are for use in such scenarios.

CODE EXAMPLE 2 is a sample servlet that consumes artifacts and dereferences assertions.

/**
 * Copyright 2004 Sun Microsystems Inc. All rights Reserved.
 */

import javax.servlet.*;
import javax.servlet.http.*;
import com.sun.identity.saml.SAMLClient;
import com.sun.identity.saml.common.SAMLException;
import com.sun.identity.saml.assertion.Assertion;

/**
 * A simple Java servlet that dereferences artifacts passed as query
 * parameter.
 */
public class TestSAMLServlet extends HttpServlet {
    public static final String ARTIFACT_ATTRIBUTE = "artifact";
    public TestSAMLServlet() {
    }
	
    public void doGet(HttpServletRequest req,
                      HttpServletResponse resp) throws ServletException {
        String[] values = req.getParameterValues(ARTIFCAT_ATTRIBUTE);
        if(values == null) {
           throw new ServletException("Artifact not found in query parameter.")
;
        }
        Assertion assertion = null;
        try {
            /**
             * Given the artifact string, this line communicates with
             * the SAML Assertion Provider, retrieves assertions, and
             * converts them to Assertion objects.
             */
             assertion = SAMLClient.getAssertionByArtifact(values[0]);
        } catch(Exception samlEx) {
            throw new ServletException("Error while dereferencing artifact.",
                                      samlEx);
        }
		try {
            PrintWriter out = resp.getWriter();
            out.println(assertion.toString());
        } catch(IOException ioex) {
            throw new ServletException("I/O error while writing assertion.",
                                       ioex);
        }
    }
}

CODE EXAMPLE 2

Note - Access Manager includes a complete set of SAML sample code in the installation_dir/SUNWam/samples/saml directory.

Liberty Alliance Project

The Liberty Alliance Project, a consortium of over 150 companies and nonprofit and government organizations, is a collaborative effort that promotes an open standard for federated identity.

Phase 1

Phase 1 of the project took advantage of existing open Web standards, such as SOAP, SAML elements, and Web services security to define an open standard for federated identity. Here are the main features:

Opt-in account linking -- Users can link accounts and maintain privacy. For example, you can link your airline mileage account to your car rental account without the airline being aware of your car rental account ID, and vice versa.
SSO -- Users can seamlessly switch between provider sites.
Single logout -- Logging out from one sites logs you out from all the sites you have accessed.
Pseudonymity -- You can pass assertions from one provider to another without identifying the subject.

Phases 2 and 3

Note - Liberty Alliance uses slightly different terminology from that in SAML for roles: "identity provider" instead of "asserting party" and "service provider" instead of "relying party."

Phase 2 of the project delivers identity-based Web services by means of three components:

Federation Framework for identity federation (ID-FF) -- An evolution of phase 1 that supports anonymity, that is, an IDP can anonymously assert to a service provider that the subject can access a service.
Web Services Framework (ID-WSF) -- Permission-based attribute sharing, profile discovery and user-interaction service. With this combination, developers can design and deploy dynamic identity-based Web services. See an example in the next section.
Service Interface Specification (ID-SIS) -- Predefined sets of attributes for common situations, such as an organization making assertions that relate to its employees.

Phase 3, which is in process, will offer specifications for a contact book, geographical locations, and presence.

An Example of ID-WSF

Here's an example of how three organizations--a cell-phone provider, a ring-tone vendor, and a bank--can cooperate by means of the Liberty Alliance standard to deliver a satisfying customer experience:

With his cell phone, a user accesses a ring-tone vendor's site. Because of SSO, the ring-tone vendor recognizes the user from the cell-phone provider's authentication and allows the user to purchase ring tones from its site, ultimately interacting with the user's bank for payment.

FIGURE 4 illustrates the architectural scheme of the example.

FIGURE 4 Architectural Scheme of an Example of ID-WSF

FIGURE 5 shows the sharing flow of the Liberty Alliance attributes.

FIGURE 5 An Example of Sharing Flow of Liberty Alliance Attributes

The process runs as follows. These steps are a summary of those in FIGURE 5:

Similarly to the SAML example, SSO is established between the cell-phone provider and the ring-tone vendor. Since the user's cell phone number is unique, he need not provide any credentials. As part of the SSO process, the ring-tone vendor receives an assertion that contains the location of the user's discovery service.
The user requests a ring tone from the ring-tone vendor.
The ring-tone vendor requests and receives the user's personal profile location from the discovery service.
The ring-tone vendor requests and receives from the bank the user's attributes, with which the vendor can use to request payment later on. Optionally, the bank can ask the user for approval of the release of the attributes. For convenience, the user could have opted to allow a number of low-value payments per day without approval.
The ring-tone vendor provides the service purchased by the user and requests payment from the bank through existing channels.

By implementing the Liberty Alliance protocols, Access Manager enables the deployment of federated identity services. A future technical article will explore Liberty Alliance in more detail and show you how to capitalize on the standards to achieve federated identity in Web applications.

Selected Q&As From Webinar

Following are a selection of Q&As from the Webinar on October 5, 2004:

Q: Has Sun renamed its identity management products?

A: Yes, Sun Java System Access Manager (called Access Manager for short) was first known as iPlanet Directory Server Access Management Edition (iDSAME), then Sun ONE Identity Server. The latest renaming was prompted by Sun's acquisition of Waveset and its provisioning product, Lighthouse. We now have a family of three identity management products: Sun Java System Access Manager, which enables SSO, access control, and federation; Sun Java System Directory Server, Enterprise Edition, which is a scalable, high-performance Lightweight Directory Access Protocol (LDAP) repository; and Sun Java System Identity Manager, which offers user provisioning, password management, and data synchronization capabilities.

Q: When do I use SAML instead of Liberty for SSO?

A: It depends on your goal. For SSO basics, SAML would suffice. For sophisticated functions, for example, global sign-outs, attribute sharing between providers, and so forth, you should use Liberty. To include the special capabilities, such as Web services, personal profile, and discovery service, Liberty is your answer.

SAML 2.0 is, in part, a merge of Liberty and SAML. If your implementation is scheduled for, say, 2005, you should move on to SAML 2.0. But then the merge makes that a moot point.

Q: How can I integrate Access Manager with a security provider that's already in use?

A: The Java Authentication and Authorization Service (JAAS) is a good way to implement authentication and authorization modules and to integrate with Access Manager. You have two options: You can either customize Access Manager to call your existing authentication and authorization module, or you can factor authentication and authorization out of your existing systems and have your non-Web applications use the Access Manager SDK to authenticate and authorize access.

Q: Can I use SAML and Liberty in products built with Java technology?

A: Sure. SAML and Liberty are available as free, open standards. Access Manager is available as part of Sun Java Enterprise System for $100 per employee per year. It's also part of Sun Java Studio Enterprise, an enterprise development platform. From the Studio Enterprise main page, you can see the package at a glance: Application Server, Web Server, Access Manager (listed as Identity Server), and so forth, along with a tutorial. You can create a simple application and see how Access Manager can protect its access. We encourage developers to download an evaluation copy.

Q: Is the SAML or Liberty technology in production? Can you cite a few real-life cases?

A: Sun is proud to point to a large number of such references. Behind the scenes, a large bank on the U. S. West Coast uses SAML for identity management of their online banking transactions. In addition, a credit aggregator for several large automobile manufacturers in the States uses Liberty to achieve federation between the aggregator itself and the manufacturers. The dealers rely on a single service that sends them credit quotes on end customers.

We cannot reveal the names of these companies, however; that's proprietary information. If you are planning a federation deployment, please send email to identity-webinar@sun.com and we'll respond on a confidential basis.

Q: Do Policy Agents log user activities locally or is logging centralized within Access Manager?

A: Access Manager Policy Agents can do both. The choice is yours.

References

Sun Java System Access Manager
Security Assertion Markup Language (SAML)
Liberty Alliance

About the Authors

Pat Patterson, a technical product manager at Sun, has been working on security and identity management since 1997, when he joined Trustbase Ltd., a software development company in London, England. After Sun acquired Trustbase in 2000, Pat became an engineering manager in secure Web services at Sun. He moved to product management in 2001.

Pirasenna Velandai Thiyagarajan is an engineering lead for Sun Java System Access Manager and the architect of Access Manager Policy Agents. He has been developing security applications for eight years.

Marina Sum is a staff writer for Sun Developer Network. She has been writing for Sun for 15 years, mostly in the technical arena.

Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.


	About Sun \| About This Site \| Newsletters \| Contact Us \| Employment \| How to Buy \| Licensing \| Terms of Use \| Privacy \| Trademarks © 2010, Oracle Corporation and/or its affiliates		A Sun Developer Network Site Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License. Sun Developer RSS Feeds