Sun™ Java System SAML v2 Plug-in for Federation Services is an auxiliary program that works with either Sun Java System Access Manager or Sun Java System Federation Manager. The plug-in incorporates a subset of features based on the Security Assertion Markup Language (SAML) version 2 specifications and, when installed, allows support for interactions based on those specifications.
This chapter covers the following topics:
SAML is an XML-based standard for communicating authentication, authorization and attribute information amongst online partners. It allows businesses to securely send data regarding the identity and entitlements of a principal between partnered organizations. The Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee is in charge of defining, enhancing, and maintaining the specifications that define SAML. SAML v2 became an OASIS-approved standard in March, 2005, incorporating the definitions from SAML v1.x with functionality from other standards (including the Liberty ID-FF v1.2 and the Shibboleth initiative). Thus, SAML v2 also takes a critical step towards convergence of many of today's federated identity standards. The SAML v2 specifications can be found on the OASIS web site.
SAML consists of a number of components that, when used together, permit the exchange of identity, authentication, and authorization information between autonomous organizations. The first component is an assertion which defines the structure and content of the information being transferred. The structure is based on the SAML v2 assertion schema. How an assertion is requested by, or pushed to, a service provider is defined as a request/response protocol encoded in its own structural guidelines: the SAML v2 protocol schema. A binding defines the communication protocols (such as HTTP or SOAP) over which the SAML protocol can be transported. Together, these three components create a profile (such as Web Browser Artifact or Web Browser POST). In general, profiles satisfy a particular use case. The following image illustrates how the components are integrated for a SAML interaction.
Two other components that may be included in SAML messages are:
Metadata defines how configuration information shared between two communicating entities is structured. For instance, an entity's support for specific SAML bindings, identifier information, and public key information is defined in the metadata. The structure of the metadata is based on the SAML v2 metadata schema. The location of the metadata is defined by Domain Name Server (DNS) records.
In some situations, one entity may want additional information to determine the authenticity of, and confidence in, the information being sent in an assertion. Authentication context permits the augmentation of assertions with information pertaining to the method of authentication used by the principal and how secure that method might be. For example, details of a multi-factor authentication can be included.
More general information on SAML can be found at the OASIS web site or in the Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide.
The SAML v2 specifications are defined more broadly with particular attention paid to functionality dealing with federation. The new specifications clean up and make enhancements to existing functionality as well as integrating features previously defined in the Liberty ID-FF v1.2 and the Shibboleth initiative. Here is a summary of some of the concepts and features of SAML v2.
This is a summary of features defined in the SAML v2 specifications. See Key Features for a list of only those supported in the Sun Java System SAML v2 Plug-in for Federation Services product.
Contains two concepts (appropriated from the Liberty ID-FF) that were not previously defined in the SAML specifications.
An identity provider is the system, or administrative domain, that asserts information about a subject. (It might also be referred to as a SAML authority, authentication authority, attribute authority, or asserting party). The identity provider might attest in a SAML assertion that a user has been authenticated because the user entered certain, associated attributes. For example, user John Doe has an email address of john.doe@acompany.com. The assertion from the identity provider might declare that John Doe was authenticated into the identity provider system by entering an email address and associated password.
A service provider is the system, or administrative domain, that relies on information supplied to it by an identity provider. (It might also be referred to as a relying party, or assertion consumer). It is the responsibility of the service provider to decide whether it trusts the identity provider from which SAML assertions are sent. The SAML assertion though does not dictate access; it is local policy that defines whether the subject may access local resources.
Supports the following bindings for exchanging request/response pairs (protocol messages):
HTTP Redirect
HTTP POST
SOAP
HTTP Artifact
Previously, only an assertion could be exchanged using HTTP Artifact. Now, any protocol message can be exchanged using the artifact binding although small-sized messages and those that are not crucial (such as logout responses) should still not use it.
Supports name identifier encryption (based on the Liberty ID-FF v1.x feature already developed for the Name ID Mapping protocol) and assertion encryption.
Supports Reverse PAOS Binding in the Enhanced Client and Proxy (ECP) context.
Supports unsolicited response.
Allows use of pseudonyms (a key privacy-enabling technology) and name identifier management (for managing pseudonyms).
Name identifier management encompasses both name registration and federation. These were separate features in the Liberty ID-FF v1.x.
Supports an identity provider discovery profile for specifying an identity provider in deployments having more than one.
Contains a metadata schema (for expressing configuration and trust-related data).
Supports encryption of attribute statements, name identifiers, or entire assertions.
Supports session management for single logout.
Support for mobile standards.
Supports affiliations.
Supports the Transient Name Identifier Format
Contains new attributes in the Name Identifier Policy, Identity Provider Proxying and Name Identifier Mapping protocols.
The Sun Java System SAML v2 Plug-in for Federation Services delivers a solution that allows businesses to establish a framework for sharing trusted information across a distributed network of partners using the standards-based SAML v2. Towards this end, HTTP(S)-based service endpoints and SOAP service endpoints are supplied in support of the respective profiles defined in the specifications as well as assertion and protocol object manipulating classes.
After installing the SAML v2 Plug-in for Federation Services, a group of companies can exchange security assertions for single sign-on when they all participate in the same SAML v2–enabled circle of trust. A web browser can access all HTTP(S)-based service endpoints and an application can make use of the SOAP endpoints and classes as long as metadata for each participating business on BOTH sides of the interaction is exchanged beforehand.
The key features of the SAML v2 Plug-in for Federation Services include:
Interoperability with the following Sun Microsystems' server products:
Access Manager 7 2005Q4
Federation Manager 7.0
The SAML v2 Plug-in for Federation Services supports all web containers and platforms used by these products.
Single sign-on using the POST profile, the Artifact binding (also referred to as HTTP redirect), and unsolicited responses (initiated by the identity provider).
Single logout using HTTP redirect and SOAP binding.
Federation termination using HTTP redirect and SOAP binding.
Auto-federation (automatic linking of service provider and identity provider user accounts based on a common attribute).
Bulk federation.
Supports one-time federation (transient NameID format in SSO).
Service provider interfaces (SPI) for the following:
Account mapping (map between the account referred to in the incoming request and the local user account).
Attribute mapping (specifies which set of user attributes in an identity provider user account need to be included in an assertion AND maps the attributes included in an assertion by the identity provider to attributes in the user account defined by the service provider).
Authentication context mapping (map between Authentication Contexts defined in the SAML v2 specifications and authentication framework schemes defined in Access Manager and Federation Manager (user/module/service/role/level based authentication).
Supports Basic Authentication, SSL and SSL with client authentication for SOAP Binding.
SAML v2 authentication module.
Support for the identity provider Discovery Protocol as the SAML v2 IDP Discovery Service.
Supports SAML v2 Circle of Trust.
A SAML v2 software development kit (SDK).
XML verification, signing, encryption and decryption.
JavaServer Pages™ (JSP™) for profile initiation and processing.
Support for load balancing.
Pre-deployment of sample.
Protocol coexistence with the SAML v1.x and the Liberty Alliance Project's Identity Federation Framework (Liberty ID-FF).
Although the SAML v2 and SAML v1.x specifications can coexist, they are not interoperable.
You can install the SAML v2 Plug-in for Federation Services on the following products and platforms.
The SAML v2 Plug-in for Federation Services is supported on Sun Java System Access Manager 7 2005Q4 in both realm and legacy mode. It can be installed on versions of the Solaris™ Operating System (OS) or Red Hat™ Linux.
Table 1–1 Access Manager Requirements
The SAML v2 Plug-in for Federation Services is supported on Sun Java System Federation Manager 7 2005Q4. It can be installed on versions of the Solaris OS.
Table 1–2 Federation Manager Requirements
Hardware |
Operating System |
---|---|
SPARC |
Solaris OS 8 / 9 / 10 |
x86 |
Solaris OS 9 / 10 |
The SAML v2 Plug-in for Federation Services consists of web-based services [using SOAP, XML over HTTP(S) or HTML over HTTP(S)], and Java™-based application provider interfaces (API) and service provider interfaces (SPI). The figure below illustrates this architecture. Additionally, the figure shows an agent embedded into a web container in which a service provider application is deployed. This agent enables the service provider to participate in the SAML or Liberty-based protocols.
A single Solaris package will be supplied along with installation and configuration scripts to setup the SAML v2 protocol endpoints as well as the SAML v2 metadata for the identity provider and the service provider. The SAML v2 Plug-in for Federation Services will leverage the core infrastructure of the underlying server product (Access Manager or Federation Manager) for authentication, authorization, service management, logging/auditing, delegation, and access to user data stores. The SAML v2 Plug-in for Federation Services is implemented as a Solaris or Linux package. Scripts to uninstall the plug-in are also supplied. More information can be found in Chapter 2, Installing the SAML v2 Plug-in for Federation Services.
In order to communicate using the SAML v2 profiles you need, at least, two instances of the installed SAML v2 Plug-in for Federation Services. One instance will act for the identity provider and the other will act for the service provider. To prepare your instances of the SAML v2 Plug-in for Federation Services for interactions, you need to exchange configuration information or metadata with all participating identity and service providers, import each provider's metadata using an XML-based metadata configuration file, and assemble the providers into a circle of trust. The SAML v2 Plug-in for Federation Services accomplishes all this administration and configuration using the command-line interface, saml2meta. Utility APIs can then be used to communicate with the data store, reading, writing, and managing the relevant properties and property values. More information can be found in Chapter 3, Administration.
Membership in a circle of trust is transient and might change over the life cycle of the circle as relationships among the partners themselves change.
The SAML v2 Plug-in for Federation Services includes Java programming tools for developer access to the SAML v2 features. They include:
The following sections contain general information about the interfaces provided with the SAML v2 Plug-in for Federation Services.
More information can be found in Chapter 5, Developer Tools and the Sun Java System SAMLv2 Plug-in for Federation Services Java API Reference.
The SAML v2 Plug-in for Federation Services provides a software development kit (SDK) containing API that can be used to construct and process assertions, requests, and responses. The SDK is designed to be plugged in although it can also be installed and run as a standalone application (without an instance of Access Manager or Federation Manager). Here is a list of the included Java API packages:
com.sun.identity.saml2.assertion
com.sun.identity.saml2.common
com.sun.identity.saml2.protocol
More information about the SAML v2 Plug-in for Federation Services SDK can be found in The SAML v2 Plug-in for Federation Services SDK and the Sun Java System SAMLv2 Plug-in for Federation Services Java API Reference.
The SAML v2 Plug-in for Federation Services provides SPI that can be implemented for application development. They are collected in the package com.sun.identity.saml2.plugins. Default implementations are provided out-of-the-box although customized implementations can be developed by modifying the appropriate attribute in the extended metadata configuration file. More information about the SPI can be found in Service Provider Interfaces and the Sun Java System SAMLv2 Plug-in for Federation Services Java API Reference.
The SAML v2 Plug-in for Federation Services provides JSP that can be used to initiate single sign-on, single logout and termination requests from either the identity provider or the service provider using a web browser. The JSP accept query parameters to allow flexibility in constructing the requests and can be modified for your deployment. More information about the JSP can be found in JavaServer Pages.