Before you set up SAML 2.0 SSO in OpenAM, you must:
-
Know which providers participate in the circle of trust.
-
Know how OpenAM installations act as identity providers, or service providers.
-
Agree with other providers on a synchronized time service.
-
For identity information exchanged with other participants in a circle of trust, define how to map shared user attributes. Local user profile attribute names should map to user profile attribute names at other providers.
For example, if you exchange user identifiers with your partners, and you call it
uidwhereas another partner calls ituserid, then you map youruidto your partner'suserid. -
Import the keys used to sign assertions into the JKS key store in your OpenAM configuration directory. You can use the Java keytool command.
The OpenAM configuration key store is located at the top level of the configuration directory, such as
$HOME/openam/keystore.jks. The password, stored in$HOME/openam/.keypass, ischangeitby default. Also by default the only key available is for a self-signed certificate (alias: test) installed with OpenAM.
During set up, you must share metadata for providers that you host with other providers in the circle of trust. You must also configure remote providers, connecting to other providers by importing their metadata.
In OpenAM terms, a hosted provider is one served by the current OpenAM server, whereas a remote provider is one hosted elsewhere.
This section covers the following topics.
Procedure 12.1. To Create a Hosted Identity Provider
-
On the OpenAM console Common Tasks page, click Create Hosted Identity Provider.
-
Unless you already have metadata for the provider, accept the Name for this identity provider in the field provided, or provide your own unique identifier.
The default name is the URL to the current server which hosts the identity provider.
-
Select the Signing Key you imported into the OpenAM key store.
-
Either add the provider to the circle of trust you already created, or select Add to new and provide a New Circle of Trust name.
-
For the attributes you share, map service provider attribute names (Name in Assertion), to user profile names from your identity repository (Local Attribute Name).
The default IDP mapping implementation allows you to add static values in addition to values taken from the user profile. You add a static value by enclosing the profile attribute name in double quotes (
"), as in the following examples.To add a static SAML attribute called
partnerIDwith a value ofstaticPartnerIDValue, addpartnerIDas the Name in Assertion with"staticPartnerIDValue"as the Local Attribute Name. -
Click Configure to save your configuration.
-
Export the XML-based metadata from your provider to share with other providers in your circle of trust.
$ curl -o metadata.xml http://www.idp.example:8080/openam/saml2/jsp/exportmetadata.jsp?entityid= http://www.idp.example:8080/openam&realm=/
realm-nameWhen you have configured only the top-level realm,
/, you can omit the query string.Alternatively, provide the URL, to other providers so they can load the metadata.
Procedure 12.2. To Create a Hosted Service Provider
-
On the OpenAM console Common Tasks page, click Create Hosted Service Provider.
-
Unless you already have metadata for the provider, accept the Name for this service provider in the field provided, or provide your own unique identifier.
The default name is the URL to the current server which hosts the service provider.
-
Either add the provider to the circle of trust you already created, or select Add to new and provide a New Circle of Trust name.
-
If the identity provider has not already mapped the attributes you share, map identity provider attribute names (Name in Assertion), to user profile names from your identity repository (Local Attribute Name).
-
Click Configure to save your configuration.
-
Export the XML-based metadata from your provider to share with other providers in your circle of trust.
$ curl -o metadata.xml http://www.sp.example:8080/openam/saml2/jsp/exportmetadata.jsp?entityid= http://www.sp.example:8080/openam&realm=/
realm-nameWhen you have configured only the top-level realm,
/, you can omit the query string.Alternatively, provide the URL, to other providers so they can load the metadata.
Procedure 12.3. To Create a Remote Identity Provider
-
Obtain the identity provider metadata, or the URL where you can obtain it.
-
On the OpenAM console Common Tasks page, click Register Remote Identity Provider.
-
Provide the identity provider metadata or link to obtain metadata.
-
Either add the provider to the circle of trust you already created, or select Add to new and provide a New Circle of Trust name.
-
Click Configure to save your configuration.
Procedure 12.4. To Create a Remote Service Provider
-
Obtain the service provider metadata, or the URL where you can obtain it.
-
On the OpenAM console Common Tasks page, click Register Remote Service Provider.
-
Provide the identity provider metadata or link to obtain metadata.
-
If the identity provider has not already mapped the attributes you share, map identity provider attribute names (Name in Assertion), to user profile names from your identity repository (Local Attribute Name).
-
Either add the provider to the circle of trust you already created, or select Add to new and provide a New Circle of Trust name.
-
Click Configure to save your configuration.
Procedure 12.5. To Create a Fedlet for Service Providers
When your organization acts as the identity provider, and you want quickly to enable service providers to federate their services with yours, you can provide them with a fedlet. A fedlet is a small Java or .NET web application that can act as a service provider for a specific identity provider without requiring that you install all of OpenAM.
Fedlets support the following SAML 2.0 features.
Table 12.1. Fedlet Support for SAML 2.0 Features
| SAML 2.0 Feature | Java Fedlet | .NET Fedlet |
|---|---|---|
| IDP & SP-initiated Single Sign-On (HTTP Artifact) | Supported | Supported |
| IDP & SP-initiated Single Sign-On (HTTP POST) | Supported | Supported |
| IDP & SP-initiated Single Logout (HTTP POST) | Supported | Supported |
| IDP & SP-initiated Single Logout (HTTP Redirect) | Supported | Supported |
| Sign Requests & Responses | Supported | Supported |
| Encrypt Assertion, Attribute, & NameID Elements | Supported | Supported |
| Export SP Metadata | Supported | Supported |
| Attribute Queries | Supported | Supported |
| XACML Requests | Supported | Not supported |
| Multiple IDPs | Supported | Supported |
| External IDP Discovery Service | Supported | Supported |
| Bundled IDP Reader Service for Discovery | Supported | Not supported |
For more information on using fedlets, see Using Fedlets in Java Web Applications and Using Fedlets in .NET Applications in the Developer's Guide.
The following procedure describes how to create a Java Fedlet.
-
If you have not done so already, set up your identity provider.
-
Enter the URL where the service provider will deploy the fedlet you create, and name the fedlet. If you create multiple fedlets, use the URL as a unique name that shows who has deployed the fedlet.
-
For the attributes you share, map service provider attribute names (Name in Assertion), to user profile names from your identity repository (Local Attribute Name).
-
Click Create to generate the
Fedlet.zipfile under the OpenAM configuration directory, such as$HOME/openam/myfedlets/httpwwwexamplecom80myapp/Fedlet.zip. -
Give the
Fedlet.zipfile to the service provider for deployment.

