Sun OpenSSO Enterprise 8.0 Administration Guide

SAMLv2 Operations

The SAMLv2 specification defines the assertion security token format as well as profiles that standardize the HTTP exchanges required to transfer XML requests and responses between an asserting authority and a trusted partner. OpenSSO Enterprise supports a number of the defined profiles. This section describes how to configure for the operations defined by the SAMLv2 profiles using OpenSSO Enterprise. It covers the following topics.

POST Binding with Single Sign-on and Single Logout

HTTP POST binding is used for an identity provider response to a request from a service provider. To configure for POST binding, the following tags must be present in the identity provider standard metadata.

<IDPSSODescriptor
WantAuthnRequestsSigned="false"
protocolSupportEnumeration="urn:oasis:names:tc:
SAML:2.0:protocol">.
  <SingleLogoutService
   Binding="urn:oasis:names:tc:SAML:2.0:
   bindings:HTTP-POST"
   Location="http://isdev-3.red.com:
   58080/fam/IDPSloPOST/metaAlias/idp"
   ResponseLocation="http://isdev-3.red.com:
   58080/opensso/IDPSloPOST/metaAlias/idp"/>
  <SingleSignOnService
   Binding="urn:oasis:names:tc:SAML:2.0:bindings:
   HTTP-POST"
   Location="http://isdev-3.red.iplanet.com:58080/opensso/
   SSOPOST/metaAlias/idp"/>
</IDPSSODescriptor>

To configure on the service provider side the standard metadata must include the following tags.

<SPSSODescriptor
 AuthnRequestsSigned="false"
 WantAssertionsSigned="false"
 protocolSupportEnumeration=
 "urn:oasis:names:tc:SAML:2.0:protocol">
.....
<SingleLogoutService
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
 Location="http://mach1.red.com:58080/opensso/
 SPSloPOST/metaAlias/sp"
 ResponseLocation="http://mach1.red.com:58080/
 opensso/SPSloPOST/metaAlias/sp"/>
</SPSSODescriptor>

idpSSOInit.jsp, spSSOInit.jsp, spSingleLogoutInit.jsp and idpSingleLogoutInit.jsp will initiate single sign-on or single logout using the proper binding. Supported values are urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect and urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST. An example URL for service provider initiated single logout might be http://mach1.red.com:58080/opensso/saml2/jsp/spSingleLogoutInit.jsp?metaAlias=/sp&idpEntityID=isdev-3.red.com&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Creating Affiliations

To configure for affiliations, the following tags must be in the identity provider standard metadata.

<AffiliationDescriptor
 affiliationOwnerID="affi.red.com">
  <AffiliateMember>mach1.red.com</AffiliateMember>
  <AffiliateMember>mach2.red.com</AffiliateMember>
</AffiliationDescriptor>

The following tags must also be present in the identity provider extended metadata.

<AffiliationConfig metaAlias="/ff">
  <Attribute name="signingCertAlias">
   <Value>test</Value>
  </Attribute>
  <Attribute name="encryptionCertAlias">
   <Value>test</Value>
  </Attribute>
</AffiliationConfig>

The ssoadm command line interface can be used to create and import the identity provider metadata. Use the following options to create the appropriate tags in the metadata. See Part I, Command Line Interface Reference, in Sun OpenSSO Enterprise 8.0 Administration Reference for more information.

--affiliation, -F: Specify a metaAlias for the hosted affiliation. The format must be realm name/identifier.
--affiscertalias, -J: Specify a signing certificate alias for the hosted affiliation.
--affiecertalias, -K: Specify an encryption certificate alias for the hosted affiliation.
--affimembers, -M: Specify affiliation members.
--affiownerid, -N: Specify the identifier for the Affiliation Owner.

An example illustrating how the command line might be used to create the metadata:

ssoadm create-metadata-templ -u amadmin 
-f /tmp/pw -m /home/tmp/affimm -x /home/tmp/affixx 
-F /ff -y affi.red.com -K test -J test -M sp1.red.com 
sp2.red.com -N affiownerID

Note –

See Chapter 1, ssoadm Command Line Interface Reference, in Sun OpenSSO Enterprise 8.0 Administration Reference for information on the other options.

idpMNIRequestInit.jsp, idpSSOInit.jsp, spMNIRequestInit.jsp and spSSOInit.jsp can initiate single sign-on based on a configured affiliation. The affiliationID parameter should match the value of the entity ID for the affiliation in the standard metadata. A URL to initiate single sign-on from the service provider might be:

http://mach1.red.com:58080/opensso/saml2/jsp/
spSSOInit.jsp?metaAlias=/sp&idpEntityID=isdev-3.red.com&reqBinding=
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&affiliationID=affi.red.com

Requesting Attribute Values Using a SAMLv2 Assertion

Providers may request attributes (and the corresponding values) from a specific identity profile. A successful response is the return of an assertion containing the requested information. The identity provider acting as the attribute authority uses an implementation of the com.sun.identity.saml2.plugins.AttributeAuthorityMapper interface to process queries. The implementation uses the attribute map table configured in the identity provider's extended metadata which maps attributes in the SAMLv2 assertion to attributes in the local user data store. (If an attribute map is not configured, no attributes will be returned.)

OpenSSO Enterprise contains two custom mappers:

com.sun.identity.saml2.plugins.DefaultAttributeAuthorityMapper: com.sun.identity.saml2.plugins.DefaultAttributeAuthorityMapper maps using the NameID from a single sign-on interaction. To set OpenSSO Enterprise to use a different attribute mapper implementation, modify the value of the default_attributeAuthorityMapper property in the extended metadata of the provider defined as the attribute authority. The mapper value of default_attributeAuthorityMapper is used for a standard attribute queries
com.sun.identity.saml2.plugins.X509SubjectAttributeAuthorityMapper: com.sun.identity.saml2.plugins.X509SubjectAttributeAuthorityMapper maps using the value of the X.509 Subject in the certificate in the NameID. To set OpenSSO Enterprise to use a different attribute mapper implementation, modify the value of the x509Subject_attributeAuthorityMapper property in the extended metadata of the provider defined as the attribute authority. The mapper value of x509Subject_attributeAuthorityMapper is used for attribute queries with an X509 certificate. The X509 mapper maps an X509 subject to a user by searching the identity data store for the attribute defined as the value of the x509SubjectDataStoreAttrName property in the identity provider extended metadata of the attribute authority. If the user has the specified attribute and the attribute's value is the same as that of the X509 subject in the attribute query, the user will be used.

Only SOAP binding is supported for these communications. Signing is required so make sure the Signing Certificate Alias attribute of any provider acting as the attribute requester and the attribute authority is configured. The ssoadm command line interface can be used to create and import the service provider metadata. The following tags must be in the standard metadata of the service provider (querying provider).

<RoleDescriptor
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:query="urn:oasis:names:tc:SAML:metadata:ext:query"
  xsi:type="query:AttributeQueryDescriptorType"
  protocolSupportEnumeration=
  "urn:oasis:names:tc:SAML:2.0:protocol">
</RoleDescriptor>

The following tags must be in the extended metadata of the service provider (querying provider).

<AttributeQueryConfig metaAlias="/attrq">
  <Attribute name="signingCertAlias">
   <Value>test2</Value>
  </Attribute>
  <Attribute name="encryptionCertAlias">
    <Value>test2</Value>
  </Attribute>
</AttributeQueryConfig>

Use the following options to create the appropriate tags in the service provider's metadata. See Part I, Command Line Interface Reference, in Sun OpenSSO Enterprise 8.0 Administration Reference for more information.

--attrqueryprovider, -S: Specify a metaAlias for the hosted querying provider. The format must be realm name/identifier.
--attrqscertalias, -A: Specify a signing certificate alias.
--attrqecertalias, -R: Specify an encryption certificate alias.

The ssoadm command line interface can also be used to create and import the identity provider metadata. The following tags must be in the standard metadata of the identity provider (attribute authority).

<AttributeAuthorityDescriptor
  protocolSupportEnumeration=
  "urn:oasis:names:tc:SAML:2.0:protocol">
</AttributeAuthorityDescriptor>

The following tags must be in the extended metadata of the identity provider (attribute authority). Note the presence of the x509SubjectDataStoreAttrName attribute.

<AttributeAuthorityConfig metaAlias="/attra">
  <Attribute name="signingCertAlias">
   <Value>test2</Value>
  </Attribute>
  <Attribute name="encryptionCertAlias">
   <Value>test2</Value>
  </Attribute>
  <Attribute name="default_attributeAuthorityMapper">
   <Value>com.sun.identity.saml2.plugins.DefaultAttributeAuthorityMapper</Value>
  </Attribute>
  <Attribute name="x509Subject_attributeAuthorityMapper">
   <Value>com.sun.identity.saml2.plugins.X509SubjectAttributeAuthorityMapper</Value>
  </Attribute>
  <Attribute name="x509SubjectDataStoreAttrName">
   <Value></Value>
  </Attribute>
</AttributeAuthorityConfig>

Use the following options to create the appropriate tags in the identity provider's metadata. See Part I, Command Line Interface Reference, in Sun OpenSSO Enterprise 8.0 Administration Reference for more information.

--attrauthority, -I: Specify a metaAlias for the hosted attribute authority. The format must be realm name/identifier.
--attrascertalias, -B: Specify a signing certificate alias.
--attraecertalias, -G: Specify an encryption certificate alias.

To initiate this query, create and import the standard and extended metadata for both the service provider and identity provider. Add the mapped values to the attributeMap property in the extended identity provider metadata in the following format:

attribute in SAML assertion=local attribute

Tip –

You can specify the attributes to be returned in the Attribute tag of the AttributeAuthorityDescriptor element of the identity provider standard metadata. If this attribute has no value, all requested attributes will be returned.

To send an attribute query from the provider use the method of com.sun.identity.saml2.profile.AttributeQueryUtil.

public static Response sendAttributeQuery(
  AttributeQuery attrQuery,
  String attrAuthorityEntityID, 
  String realm, 
  String attrQueryProfile,
  String attrProfile, String binding) throws SAML2Exception;

To construct an AttributeQuery object, use the com.sun.identity.saml2.assertion.* and com.sun.identity.saml2.protocol.* packages.

Requesting a SAMLv2 Assertion

The Assertion Query/Request profile specifies a means for requesting existing assertions using a unique identifier. The requester initiates the profile by sending an assertion request, referenced by the identifier, to a SAMLv2 authority. The SAMLv2 authority processes the request, checks the assertion cache for the identifier, and issues a response to the requester.

Note –

To store assertions generated during single sign-on, add the following attribute to the metadata file of the identity provider acting as the SAMLv2 authority.

<IDPSSOConfig metaAlias="/idp">
<Attribute name="assertionCacheEnabled">
<Value>true</Value>
</Attribute>
</IDPSSOConfig>

To configure for assertion queries, the following tags must be defined in the identity provider standard metadata.

<IDPSSODescriptor WantAuthnRequestsSigned=
"false" protocolSupportEnumeration="urn:oasis:names:tc:
SAML:2.0:protocol">

  <AssertionIDRequestService Binding="urn:oasis:names:tc:
   SAML:2.0: bindings:SOAP" Location=
   "http://isdev-3.red.iplanet.com:58080/
   fam/AIDReqSoap/IDPRole/metaAlias/idp"/>
    <AssertionIDRequestService Binding=
     "urn:oasis:names:tc:SAML:
     2.0:bindings:URI" Location=
     "http://isdev-3.red.iplanet.com:
     58080/fam/AIDReqUri/IDPRole/metaAlias/idp"/>
</IDPSSODescriptor>

<AttributeAuthorityDescriptor protocolSupportEnumeration=
"urn:oasis:names:tc:SAML:2.0:protocol">
  <AssertionIDRequestService Binding=
   "urn:oasis:names:tc:SAML:
   2.0:bindings:SOAP" Location=
   "http://isdev-3.red.iplanet.com:
   58080/fam/AIDReqSoap/AttrAuthRole/metaAlias/attra"/>
    <AssertionIDRequestService Binding=
     "urn:oasis:names:tc:SAML:
     2.0:bindings:URI" Location=
     "http://isdev-3.red.iplanet.com:
     58080/fam/AIDReqUri/AttrAuthRole/
     metaAlias/attra"/>
</AttributeAuthorityDescriptor>

<AuthnAuthorityDescriptor protocolSupportEnumeration=
"urn:oasis:names:tc:SAML:2.0:protocol">
..<AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:
   2.0:bindings:SOAP" Location="http://isdev-3.red.iplanet.com:
   58080/fam/AIDReqSoap/AuthnAuthRole/metaAlias/authna"/>
  <AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:
   2.0:bindings:URI" Location="http://isdev-3.red.iplanet.com:
   58080/fam/AIDReqUri/AuthnAuthRole/metaAlias/authna"/>
..</AuthnAuthorityDescriptor>

The following tags must be defined in the identity provider extended metadata.

<IDPSSOConfig metaAlias="/idp">
..<Attribute name="assertionIDRequestMapper">
   <Value>com.sun.identity.saml2.plugins.
    DefaultAssertionIDRequestMapper</Value>
   </Attribute>
</IDPSSOConfig>

<AttributeAuthorityConfig metaAlias="/attra">
..<Attribute name="assertionIDRequestMapper">
   <Value>com.sun.identity.saml2.plugins.
    DefaultAssertionIDRequestMapper</Value>
  </Attribute>
</AttributeAuthorityConfig>

<AuthnAuthorityConfig metaAlias="/authna">
..<Attribute name="assertionIDRequestMapper">
   <Value>com.sun.identity.saml2.plugins.
    DefaultAssertionIDRequestMapper</Value>
  </Attribute>
</AuthnAuthorityConfig>

com.sun.identity.saml2.plugins.DefaultAssertionIDRequestMapper is the default implementation used to process the assertion request. (See com.sun.identity.saml2.plugins.AssertionIDRequestMapper in the Sun OpenSSO Enterprise 8.0 Java API Reference.) To define a customized mapper, change the value of the assertionIDRequestMapper property in the IDP, attribute authority or authentication authority extended metadata.

Supported bindings are SOAP and URI however in order to implement URI binding, you must do the following.

Write an implementation of com.sun.identity.saml2.plugins.AssertionIDRequestMapper.

The method authenticateRequesterURI() should be returned without throwing an exception.
Modify the value of the assertionIDRequestMapper element in the identity provider metadata to match the name of the custom implementation.

To send a request for an assertion from a service provider use either of the methods of com.sun.identity.saml2.profile.AssertionIDRequestUtil as below.

public static Response sendAssertionIDRequest(
  AssertionIDRequest assertionIDRequest, String samlAuthorityEntityID,
  String role, String realm, String binding) throws SAML2Exception;

public static Assertion sendAssertionIDRequestURI(
  String assertionID, String samlAuthorityEntityID,
  String role, String realm) throws SAML2Exception;

To construct an AssertionIDRequest object, use com.sun.identity.saml2.assertion.* and com.sun.identity.saml2.protocol.*.

Requesting a SAMLv2 Assertion for Authentication Context

A SAMLv2 assertion contains information regarding the context of a principal's authentication. The requesting party may require this additional information (for example, the authenticating technology or protocol used) in order to assess the level of confidence they can place in the assertion. To retrieve authentication context information, the service provider issues a query to the authentication authority. Only SOAP binding is supported for this request And signing is required so make sure the Signing Certificate Alias attribute of the service provider and the authentication authority is configured.

To Configure for Authentication Context Queries

Create and load the metadata for the service provider.

Create the metadata for the identity provider using ssoadm and define these additional options for it's role as an authentication authority.

-C

Defines the meta Alias for the hosted authentication authority to be created. The format must be realm name/identifier.

-D

Defines the authentication authority signing certificate alias.

-E

Defines the authentication authority encryption certificate alias.

For example:
```
ssoadm create-metadata-templ -u amadmin -f /tmp/pw -m /home/user1/tmp/mm -x
/home/usr1/tmp/xx -s /idp -a test -r test -C /authna -D test2 -E test2 -y
example.com
```

Add the following attribute to the identity provider metadata file just created.

This allows the identity provider to store assertions generated during the SAMLv2 Single Sign-on process.
```
<IDPSSOConfig metaAlias="/idp">
<Attribute name="assertionCacheEnabled">
<Value>true</Value>
</Attribute>
</IDPSSOConfig>
```

Configure for SAMLv2 single sign-on as documented in Configuring SAMLv2 Single Sign-on without Service Provider User Accounts.

Do either of the following:
- To send an authentication query from the service provider use the method of com.sun.identity.saml2.profile.AuthnQueryUtil.
```
public static Response sendAuthnQuery(AuthnQuery authnQuery,
  String authnAuthorityEntityID, String realm, String binding)
  throws SAML2Exception;
```
- To construct an AuthnQuery object, use com.sun.identity.saml2.assertion.* and com.sun.identity.saml2.protocol.*.

Encoding Artifacts

When an identity provider sends a response to a service provider using artifact binding, OpenSSO Enterprise supports either URI or form encoding. To specify the encoding, toggle the value of the responseArtifactMessageEncoding tag in the service provider's extended metadata. Possible values are URI and FORM as in:

<Attribute name="responseArtifactMessageEncoding">
  <Value>FORM</Value>
</Attribute>

Managing SAMLv2 Name Identifiers

With this release, OpenSSO Enterprise enhances its implementation of the Name Identifier Management Profile to include the termination of the association of a name identifier between a service provider and an identity provider (including the accompanying federation) and the issuance of a new name identifier. When metadata is created using OpenSSO Enterprise, XML is defined to support HTTP-Redirect, SOAP and HTTP-POST bindings. Following is the code for an identity provider.

<IDPSSODescriptor
  <ManageNameIDService
   Binding="urn:oasis:names:tc:SAML:2.0:bindings:
   HTTP-Redirect" Location="http://isdev-3.red.iplanet.com:
   58080/fam/IDPMniRedirect/metaAlias/idp" ResponseLocation=
   "http://isdev-3.red.iplanet.com:58080/fam/IDPMniRedirect/
   metaAlias/idp"/>
  <ManageNameIDService
   Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
   Location="http://isdev-3.red.iplanet.com:58080/fam/
   IDPMniPOST/metaAlias/idp" ResponseLocation=
   "http://isdev-3.red.iplanet.com:58080/fam/IDPMniPOST/
   metaAlias/idp"/>
  <ManageNameIDService
   Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
   Location="http://isdev-3.red.iplanet.com:58080/fam/
   IDPMniSoap/metaAlias/idp"/>
</IDPSSODescriptor>

The ManageNameID (MNI) JSP provide a way to initiate name identifier changes or terminations. For example, after establishing a name identifier for use when referring to a principal, the identity provider may want to change its value and/or format. Additionally, an identity provider might want to indicate that a name identifier will no longer be used to refer to the principal. The identity provider will notify service providers of the change by sending them a ManageNameIDRequest. A service provider also uses this message type to register or change the SPProvidedID value (included when the underlying name identifier is used to communicate with it) or to terminate the use of a name identifier between itself and the identity provider. To initiate termination of a name identifier or creation of a new identifier, access the appropriate JSP using the URL and URL parameter information in the following sections.

The JSP are located in /OpenSSO-Deploy-base/opensso/saml2/jsp/. idpMNIRedirect.jsp, spMNIRedirect.jsp, idpMNIPOST.jsp, and spMNIPOST.jsp, also in that directory, are process pages served as endpoints.

`idpMNIRequestInit.jsp`

idpMNIRequestInit.jsp initiates name identifier modifications or termination from the identity provider. The URL for this JSP is protocol://host:port/service-deploy-uri/saml2/jsp/idpMNIRequestInit.jsp. The following URL parameters are appended to it.

metaAlias: The value of the metaAlias property set in the identity provider's extended metadata configuration file. If the metaAlias attribute is not present, an error is returned.
spEntityID: The entity identifier of the service provider to which the response is sent.
requestType: The type of ManageNameIDRequest. Accepted values include Terminate and NewID.
binding: A URI specifying the binding to use for the communications. The supported values are:
- urn:oasis:names:tc:SAML:2.0:bindings:SOAP
- urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
- urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
RelayState: The target URL of the request.

An example URL for using HTTP-POST communication might be:

http://dev-3.sun.com:58080/opensso/saml2/
  jsp/idpMNIRequestInit.jsp?metaAlias=/idp&spEntityID=
  mach1.sun.com&requestType=Terminate&binding=
  urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

`spMNIRequestInit.jsp`

spMNIRequestInit.jsp initiates name identifier modifications or termination from the service provider. The URL for this JSP is protocol://host:port/service-deploy-uri/saml2/jsp/spMNIRequestInit.jsp. The following URL parameters are appended to it.

metaAlias: This parameter takes as a value the metaAlias set in the identity provider's extended metadata configuration file. If the metaAlias attribute is not present, an error is returned.
idpEntityID: The entity identifier of the identity provider to which the request is sent.
requestType: The type of ManageNameIDRequest. Accepted values include Terminate and NewID.
binding: A URI specifying the protocol binding to use for the Request. The supported values are:
- urn:oasis:names:tc:SAML:2.0:bindings:SOAP
- urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
- urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
RelayState: The target URL of the request.

An example URL for using SOAP communication might be:

http://dev-3.sun.com:58080/opensso/saml2/
  jsp/idpMNIRequestInit.jsp?metaAlias=/sp&idpEntityID=
  mach1.sun.com&requestType=NewID&binding=
  urn:oasis:names:tc:SAML:2.0:bindings:SOAP

Mapping SAMLv2 Name Identifiers

The NameID Mapping Protocol allows a service provider that shares an identifier for a principal with an identity provider to obtain a name identifier for said principal in another format or that is in another federation namespace (for example, is shared between the identity provider and another service provider). The requester initiates the profile by sending a NameIDMappingRequest message to the identity provider. After processing the request, the identity provider issues a NameIdMappingResponse message to the requester.

Only SOAP binding is supported. Signing is required so make sure the Signing Certificate Alias attribute of the identity provider and the service provider is configured.

To send a NameIDMappingRequest message from the service provider, use the method of the com.sun.identity.saml2.profile.NameIDMapping.

public static NameIDMappingResponse initiateNameIDMappingRequest(
  Object session,
  String realm, 
  String spEntityID, 
  String idpEntityID,
  String targetSPEntityID, 
  String targetNameIDFormat,
  Map paramsMap) throws SAML2Exception;

Enhanced Client and Proxy

The Enhanced Client and Proxy (ECP) profile assumes the client can contact an appropriate provider using the reverse SOAP (PAOS) binding. The ECP process flow is as follows:

The principal, through the ECP, makes an HTTP request for a secured resource at a service provider, which does not have an established security context for the ECP or principal.
The service provider issues an authentication request to the ECP using PAOS binding.
The ECP obtains the location of an endpoint at an identity provider for the authentication request protocol that supports its binding.
The ECP conveys the authentication request to the identity provider.
The identity provider identifies the principal.
The identity provider issues a response to the ECP that is to be delivered to the service provider.
The ECP conveys a response message to the service provider.
The service provider grants or denies access to the principal.

See the following procedures for configuration information.

After completing the configuration, use the following URL format to access a resource on the service provider.

SP protocol://SP host:SP port/SP deploy URI/SPECP?metaAlias=sp metaAlias&RelayState=resource url

To Configure for ECP on the Identity Provider Side

Click the Federation tab and select the hosted SAMLv2 identity provider you wish to edit.

Click on the IDP tab.

Click the Advanced tab.

Edit the IDP Session Mapper attribute for you deployment.

The session mapper SPI com.sun.identity.saml2.plugins.IDPECPSessionMapper finds a valid session from the HTTP servlet request on the identity provider side with the ECP profile. The default implementation will construct a session object from the OpenSSO Enterprise server cookie. To construct a session from other cookies or HTTP headers, you need to implement this SPI and set your implementation here.

Click Save.

To Configure for ECP on the Service Provider Side (Optional)

Click the Federation tab and select the hosted SAMLv2 identity provider you wish to edit.

Click on the SP tab.

Click the Advanced tab.

Click ECP Configuration.

Edit Request IDP List Finder Implementation the IDP Finder SPI.

com.sun.identity.saml2.plugins.SAML2IDPFinder finds a list of preferred identity providers. You can write your own implementation of this interface and set it here. The default implementation will read Request IDP List attribute. Request IDP List Get Complete Specifies an URI reference that can be used to retrieve the complete IDP list if the IDPList element is not complete. Request IDP List Defines a list of IDPs for the ECP to contact. This is used by the default implementation of the IDP Finder.

Click Save.

Formatting Name Identifiers

Name identifiers are used by the identity provider and the service provider to communicate with each other regarding a principal. As of this release, OpenSSO Enterprise supports the following name identifier formats.

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified (enabled by default)
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress (enabled by default)
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
urn:oasis:names:tc:SAML:2.0:nameid-format:entity
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (enabled by default)
urn:oasis:names:tc:SAML:2.0:nameid-format:transient (enabled by default)

OpenSSO Enterprise defines these name identifiers in the identity provider's standard metadata. If no specific name identifier format is requested by the service provider, a default format must be used in the authentication response. To enable one or more of the supported formats you must add a name identifier format/user attribute map to the identity provider extended metadata to generate the name identifier based on the specified user profile attribute. The value is formatted as name ID format=user profile attribute as in the following XML sample

<Attribute name="nameIDFormatMap">
  <Value>urn:oasis:names:tc:SAML:1.1:nameid-format:
   emailAddress=mail</Value>
  <Value>urn:oasis:names:tc:SAML:1.1:nameid-format:
   X509SubjectName=</Value>
  <Value>urn:oasis:names:tc:SAML:1.1:nameid-format:
   WindowsDomainQualifiedName=</Value>
  <Value>urn:oasis:names:tc:SAML:2.0:nameid-format:
   kerberos=</Value>
</Attribute>

If a user profile attribute is specified, the name ID value will be the value of the user profile attribute. If no user profile attribute is specified an exception will be thrown. If the name ID format is persistent or transient, a random string will be generated. For more information on persistent and transient identifiers, see Configuring SAMLv2 Single Sign-on without Service Provider User Accounts.

Note –

To disable one or more name ID formats, the format XML tags can be removed from the identity provider's standard metadata.

Configuring SAMLv2 Single Sign-on without Service Provider User Accounts

Name identifiers are used by the identity provider and the service provider to communicate with each other regarding a user. Single sign-on interactions can support both persistent and transient identifiers. A persistent identifier is saved to a particular user entry as the value of two attributes. A transient identifier is temporary and no data will be written to the user's data store entry. OpenSSO Enterprise supports persistent identifiers by default and transient identifiers with configuration. NameID formats other than persistent and transient are supported by mapping the NameID format to a user profile attribute.

In some deployments, there might be no user account on the service provider side of an interaction. In this case, single sign-on with the transient name identifier is used. All users passed from the identity provider to the service provider will be mapped to this one user account. All attributes defined in the AttributeStatement will be set as properties of the specific user's single sign-on token. The following procedures describe some interactions using the transient name identifier.

To Use the Transient Name Identifier

Append the NameIDFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient query parameter to the URL that initiates a single sign-on JavaServer Page™ (JSP™).

spSSOInit.jsp and idpSSOInit.jsp both initiate single sign-on interactions.

To test, invoke the URL.

For more information, see Sun OpenSSO Enterprise 8.0 Developer’s Guide.

To Federate Disparate Accounts with Auto Federation

The auto-federation feature in OpenSSO Enterprise will automatically federate a user's disparate provider accounts based on a common attribute. This common attribute will be exchanged in a single sign-on assertion so that the consuming service provider can identify the user and create account federations. If auto-federation is enabled and it is deemed that a user at provider A and a user at provider B have the same value for the defined common attribute (for example, emailaddress), the two accounts will be federated automatically without principal interaction.

Note –

Auto-federating a principal's two distinct accounts at two different providers requires each provider to have agreed to implement support for this functionality beforehand.

Ensure that each local service and identity provider participating in auto federation is configured for it. Remote providers would not be configured in your deployment.

In the OpenSSO Enterprise Console, click the Federation tab.

Select the name of the hosted identity provider to edit its profile.

Click the Assertion Processing tab.

In the Attribute Map attribute, add the autofedAttribute=local-attribute value. For example, employeeNumber=employeeID.

Click Save.

Go back to the Federation tab and select the name of the hosted service provider to edit its profile.

If the Auto Federation Common Attribute Name is the same as local attribute name, skip to next step. If not, enter the autofedAttribute=local-attribute value in the New Value field under Attribute Map. For example:

employeeNumber=employeeID

Click on the Auto Federation link at the top of the page, or scroll down to the Auto Federation subsection.

Enable Auto Federation by checking the box.

Click Save to complete the configuration.

To Map Attributes to `anonymous` User Account

In some deployments, the service provider side of an interaction might not store user accounts. The single sign-on solution is for all identity provider user accounts to be mapped to one service provider user account. Any attributes inside the Attribute Statement will be set as properties of the single sign-on token. The following procedure maps an identity provider user to a service provider anonymous user and passes two attributes to the service provider.

In the console, select the identity provider you wish to configure.

Edit Attribute Map attribute.

attribute Map defines the mapping between the provider that this metadata is configuring and the remote provider. This attribute takes a value of autofedAttribute-value=remote-provider-attribute. For example:
```
mail=mail
employeeNumber=employeeNumber
```

From the console, select the service provider you wish to configure.

Edit the following attributes for the service provider.
- transient User will take a value of one of the existing transient user identifiers on the service provider side, for example, anonymous.
- attribut eMap defines the mapping between the provider that this metadata is configuring and the remote provider. This attribute takes a value of autofedAttribute_value=remote_provider_attribute. For example:
```
>mail=mail
employeeNumber=employeeNumber
```

To test, invoke the single sign-on URL with the NameIDFormat=transient query parameter appended to it.

All identity provider users will be mapped to anonymous on the service provider side. mail and employeeNumber will be set as properties in the identity provider user's single sign-on token.

To Achieve Single Sign-on Without Data Store Writes

This interaction uses auto-federation with the transient name identifier. There is one-to-one mapping between user accounts configured with the identity provider and the service provider based on the value of one attribute. The following procedure describes how to configure single sign-on without writing to the user's data store entry.

Edit the following attributes in the OpenSSO Enterprise console for the identity provider.
- Auto Federation – enable this attribute.
- Auto Federation Attribute defines the common attribute on the identity provider side. For example, mail.
- Attribute Map defines the mapping between the identity provider's attribute and the remote provider's attribute. It takes a value of autofedAttribute-value=remote-provider-attribute. For example:
```
<Attribute name="attributeMap">
<Value>mail=mail</Value>
</Attribute>
```

Edit the following attributes in the OpenSSO Enterprise console for the service provider.
- Transient User takes a null value.
- Auto Federation enable this attribute.
- Auto Federation Attribute defines the common attribute. For example, mail.
- Attribute Map defines the mapping between the provider that this metadata is configuring and the remote provider. This attribute takes a value of autofedAttribute-value=remote-provider-attribute. For example:
```
mail=mail
```

Invoke the single sign-on URL with the NameIDFormat=transient query parameter appended to it to test.

All identity provider users will be mapped to the corresponding user on the service provider side based on the mail attribute but the auto-federation attributes will not be written to the user entry.

Auto-creation of User Accounts

Auto-creation of user accounts can be enabled on the service provider side. An account would be created when there is none corresponding to the identity provider user account requesting access. This might be necessary, for example, when a new service provider has joined an existing circle of trust.

Note –

Auto-creation is supported only when the service provider is running on an instance of OpenSSO Enterprise as it extends that product's Dynamic Profile Creation functionality.

To Enable Auto-creation

Before You Begin

You must configure the attribute mapper on the identity provider side to include an AttributeStatement from the user. The account mapper on the service provider side will perform user mapping based on the AttributeStatement.

Enable auto Federation for the Identity Provider. For more information, see To Federate Disparate Accounts with Auto Federation.

Click Save.

Repeat the above steps to modify the service provider's extended metadata.

Enable Dynamic Profile Creation using the OpenSSO Enterprise console.
1. Log in to the OpenSSO Enterprise console as the top-level administrator, by default, amadmin.
2. Under the Access Control tab, select the appropriate realm.
3. Select the Authentication tab.
4. Select Advanced Properties.
5. Set User Profile to Dynamic or Dynamic with User Alias and click Save.
6. Log out of OpenSSO Enterprise.

To test, invoke single sign-on from the service provider.

Using Non-Default Federation Attributes

If OpenSSO Enterprise is retrieving data from an LDAPv3–compliant directory, the object class sunFMSAML2NameIdentifier (containing two allowed attributes, sunfm- saml2-nameid-info and sun-fm-saml2-nameid-infokey) needs to be loaded into the entries of all existing users. When the directory contains a large user database the process is time-intensive. The following procedure can be used to modify your SAML v2 Plug-in for Federation Services installation to use existing LDAP attributes to store user federation information. In this case, there is no need to change the schema.

To Store Federation Information in Existing Attributes

In the OpenSSO Enterprise console, go to Configuration>Global>SAMLv2 Service Configuration.

Modify the following attributes:
- Attribute name for Name ID information
- Attribute name for Name ID information key
See SAMLv2 Service Configuration in Sun OpenSSO Enterprise 8.0 Administration Reference for more information.

Restart the web container.

Federation information will now be written to the specified attributes.

Enabling XML Signing and Encryption

XML signing and encryption is most easily configured through the OpenSSO Enterprise console. To enable request/response signing and encryption, click on the name of the entity provider you wish to edit in the Federation tab. For both service and identity providers, the signing attributes are located under the Assertion Content sub tab.

For definitions for service provider attributes, see SAMLv2 Service Provider Customization in Sun OpenSSO Enterprise 8.0 Administration Reference.

For definitions of identity provider attributes, see SAMLv2 Identity Provider Customization in Sun OpenSSO Enterprise 8.0 Administration Reference.

Securing SOAP Binding

SOAP binding supports the following authentication methods to protect interactions between SAML v2 entities:

Basic Authentication

Once basic authentication is set up to protect a SAML v2 SOAP endpoint, all entities communicating with this endpoint must configure three basic authentication-related attributes in the extended metadata as described in the following table. These attributes are located in the Assertion Content tab of the SAMLv2 entity provider profile.

Table 8–2 Securing SOAP Endpoint with Basic Authentication


Attribute	Description
`Basic Authenticaion Enabled`	Establishes that the SOAP endpoint is using basic authentication. Takes a value of `true` or `false`.
`User Name`	Defines the user allowed access to the protected SOAP endpoint in the original SAML v2 entity.
`Password`	Defines an encrypted password for the user. The password is encrypted using `ampassword` on the partner side. .

Secure Socket Layer/Transport Layer Security

Secure Socket Layer/Transport Layer Security (SSL/TLS) can also be enabled to protect SOAP endpoints and secure communications between SAML v2 entities. When one SAML v2 entity initiates communication with a SAML v2 entity deployed in an SSL/TLS-enabled web container, the initiating entity is referred to as the SSL/TLS client and the replying entity is referred to as the SSL/TLS server.

Server Certificate Authentication

For SSL/TLS server authentication (the server needs to present a certificate to the client), the following properties need to be set in the Virtual Machine for the Java™ platform (JVM™) running the SSL/TLS client:

`-Djavax.net.ssl.trustStore`	Defines the full path to the file containing the server's CA certificates.
`-Djavax.net.ssl.trustStoreType`	Takes a value of `JKS` (Java Key Store).

In addition, the client's CA certificate needs to be imported into the certificate store/database of the server's web container and marked as a trusted issuer of client certificates.

Client Certificate Authentication

For SSL/TLS client authentication (the client needs to present a certificate to the server), the following properties need to be set in the JVM software running the SSL/TLS client:

`-Djavax.net.ssl.keyStore`	Defines the full path to the keystore containing the client certificate and private key. This may be the same as that defined in Server Certificate Authenticaion..
`-Djavax.net.ssl.keyStoreType`	Takes a value of `JKS`.
`-Djavax.net.ssl.keyStorePassword`	Specifies the password to the keystore.

On the SSL/TLS server side, the client's CA certificate needs to be imported into the web container's keystore and marked as a trusted issuer of client certificates.

Load Balancing

In cases of large deployments, a load balancer can be put in front of multiple instances of OpenSSO Enterprise that have the SAML v2 Plug-in for Federation Services installed. The following procedure describes how to enable load balancer support.

To Enable Load Balancer Support

Install OpenSSO Enterprise and follow the documentation to set up a load balancer.

Load balancing information for OpenSSO Enterprise can be found in Configuring the Directory Server Load Balancer in Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0.

Create an identity provider or a service provider through the OpenSSO Enterprise Console or with the ssoadm CLI.
- Use the load balancer URL, not the server URL, to access the console. For information on creating an entity provider, see To Create a SAMLv2 Entity Provider.
- To create the provider through the command line, see Managing Federation Using ssoadm.

On any service provider machines, copy the metadata configuration files into the same directory and rename as follows:
- spMeta.xml to spMeta.xml.lb
- spExtended.xml to spExtended.xml.lb

Edit the new service provider load balancer metadata configuration files as follows:
- Change the host name of the service provider to that of the load balancer on the service provider side.
- Change the protocol on the service provider side.
- Change the port of the service provider to that of the load balancer on the service provider side.
- Change the metaAlias of the service provider to any new metaAlias, for example, /splb.

On any identity provider machines, copy the metadata configuration files into the same directory and rename as follows:
- idpMeta.xml to idpMeta.xml.lb
- idpExtended.xml to idpExtended.xml.lb

Edit the new identity provider load balancer metadata configuration files as follows:
- Change the host name of the identity provider to that of the load balancer on the identity provider side.
- Change the protocol on the identity provider side.
- Change the port of the identity provider to that of the load balancer on the identity provider side.
- Change the metaAlias of the identity provider to any new metaAlias, for example, /idplb.

Import the new hosted metadata onto the service provider machines.

Import the new remote identity provider metadata onto the service provider machines.

Import the new hosted metadata onto the identity provider machines.

Import the new remote service provider metadata onto the identity provider machines.

Restart the web containers.

Access Control

The following procedure will allow user access on the service provider side based on the user's configured roles on the identity provider side. This information is passed to the service provider in an assertion. No matching user entry is necessary on the service provider side.

To Enable Access Control Using Agents

You must configure the agent to enforce policy. For example, setting com.sun.am.policy.agents.config.do_sso_only=false.
You must configure the attribute mapper on the identity provider side to include the required attributes in the AttributeStatment.
You must configure the service provider to set the received attributes as key/value pairs in the user's single sign-on token. The agent will set those attributes in the HTTP header, passing them down to the application.

Create a SAMLv2 identity provider. For more information, see To Create a SAMLv2 Entity Provider.

Create a SAMLv2 service provider.

Install the Sun Policy Agents 3.0 to protect the service provider configured on the instance of OpenSSO Enterprise

For more information, see the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for Web Agents.

In the OpenSSO Enterprise console, go to Access Control>Realms>Agents and select the web policy agent profile you wish to configure.

Go to the OpenSSO Services sub tab and edit the OpenSSO Login URL attribute .

Its value is a URL (appended with the NameIDFormat=transient query parameter) that points to a single sign-on JSP on the service provider side.

SP-protocol://SP-host:SP-port/service-deploy-uri/
saml2/jsp/spSSOInit.jsp?NameIDFormat=transient&metaAlias=SP-metaAlias&
idpEntityID=IDP_EntityID

For example:

http://example1.com:58080/
opensso/saml2/jsp/spSSOInit.jsp?NameIDFormat=transient&metaAlias=/sp&
idpEntityID=sample.com

(Required only if using Web Agent 2.1) Set the value of the com.sun.am.policy.am.library.loginURL property to the service provider's login URL so the agent can authenticate itself.

If the login URL is a URL that initiates a SAML v2 single sign-on interaction, the value of this property will be used to authenticate the agent itself to your instances of OpenSSO Enterprise. An example value might be http://host:port/opensso/UI/Login.

Modify spSSOInit.jsp on the service provider side to use goto parameter as the value for RelayState.

The differences are as follows:

***************
*** 143,148 ****
--- 143,154 ----
}
idpEntityID = request.getParameter("idpEntityID");
paramsMap = SAML2Utils.getParamsMap(request);
+ String gotoURL = (String) request.getParameter("goto");
+ if (gotoURL != null) {
+ List list = new ArrayList();
+ list.add(gotoURL);
+ paramsMap.put(SAML2Constants.RELAY_STATE, list);
+ }
if ((idpEntityID == null) || (idpEntityID.length() == 0)) {
// get reader url

Set up single sign-on without requiring writes to the data store by following the procedure described in To Achieve Single Sign-on Without Data Store Writes.

To test, assume the employeenumber attribute stores the user's role. In addition, the identity provider should have the following configured users:
- User 1 has employeenumber set to manager (the manager's role).
- User 2 has employeenumber set to employee (the employee's role).

Create a policy with the Session Property condition on the service provider instance of OpenSSO Enterprise.
1. Log in to the OpenSSO Enterprise console as the top-level administrator, by default, amadmin.
2. Under the Access Control tab, select the appropriate realm.
3. Select the Policies tab.
4. Click New Policy.
5. Enter a name for the policy.
6. Click New under Rules.
7. Select URL Policy Agent (with resource name) and click Next.
8. Enter a name for the rule.
9. Enter the application's URL as the value for Resource Name.
10. Select Allow under both GET and POST and click Finish.
11. Click New under Conditions.
12. Select Session Property and click Next.
13. Enter a name for the condition.
14. Click Add under Values.
15. Enter the single sign-on token property name as the value for Property Name.
  
  To test, use employeenumber.
16. Add the match value to the Values field and click Add.
  
  To test, use manager.
17. Click Add to return to the New Condition page.
18. Click Finish to save the condition.
19. Click Create to create the policy.
For more information on creating policy, see Creating Policies and Referrals.

Access the application using a web browser.

You will be redirected to the service provider single sign-on JSP defined in the previous step. From there, you will be redirected to the identity provider to login. Single sign-on with the service provider will be accomplished using SAML v2 and, finally, you will be redirected back to the application for policy enforcement. If you logged in as User 1, you will be allowed to access the application as a manager which is allowed by the policy. If you logged in as User 2, an employee, you will be denied access to the application.

Certificate Revocation List Checking

The certificate revocation list (CRL) is a list of revoked certificates that contains the reasons for the certificate's revocation, the date of it's issuance, and the entity that issued it. When a potential user attempts to access the OpenSSO Enterprise server, first access is allowed or denied based on the CRL entry for the root certificate included with the request. When the SAML v2 Service receives the incoming XML request, it parses the issuer Distinguished Name (DN) from the root certificate and retrieves the value defined by the com.sun.identity.crl.cache.directory.searchattr attribute in the Advanced properties of the Sites and Server tab. For more information, see Advanced in Sun OpenSSO Enterprise 8.0 Administration Reference. If the attribute value is CN and the issuer DN is, for example, CN="Entrust.net Client Certification Authority", OU=..., the SAML v2 Service uses Entrust.net Client Certification Authority to retrieve the CRL from the LDAP directory which acts as the CRL repository.

With this action, one of the following will occur:

If the LDAP directory returns a CRL that is not valid, the SAML v2 Service retrieves the value of the IssuingDistributionPointExtension attribute (usually an HTTP or LDAP URI) from the CRL and uses it to get new CRL from the certificate authority. If the certificate authority returns a valid CRL, it is saved to the LDAP directory and to memory and used for certificate validation.
If the LDAP directory returns no CRL but the certificate that is being validated has a defined CRL Distribution Point Extension, the SAML v2 Service retrieves it's value (usually an HTTP or LDAP URI) and uses the value to get a new CRL from the certificate authority. If the certificate authority returns a valid CRL, it is saved to the LDAP directory and to memory and used for certificate validation.
If the certificate authority returns a valid CRL, it is saved to the LDAP directory and to memory and used for certificate validation.

Note –

Currently, Certificate Revocation List Checking works only with an instance of Sun Directory Server.

After the CRL is loaded into memory and the root certificate validation is successful, the single sign-on process continues with validation of the signed XML message. The following are procedures to set up the SAML v2 Service for CRL checking.

Caution –

CRL checking currently only works in the case of XML-based signature validation; for example, service provider side POST Artifact profile, or SOAP based logout. CRL checking does not work in the case of URL string based signature validation, XML signing, XML encryption or decryption.

To Set Up for Certificate Revocation List Checking

Before You Begin

A local instance of Directory Server must be designated as the CRL repository. It can be the same directory in which the OpenSSO Enterprise schema is stored or it can be standalone. The Java Development Kit (JDK) must be version 1.5 or higher.

Create one entry in Directory Server for each certificate authority.

For example, if the certificate authority's subjectDN is CN="Entrust.net Client Certification Authority",OU="www.entrust.net/GCCA_CPS incorp. by ref. (limits lib.)",O=Entrust.net and the base DN for Directory Server is dc=sun,dc=com, create an entry with the DN cn="Entrust.net Client Certification Authority",ou=people,dc=sun,dc=com.

Note –
If the certificate authority's subjectDN does not contain uid or cn attributes, do the following:
1. Create a new object class.
  
  For example, sun-am-managed-ca-container.
2. Populate the new object class with the following attributes:
  - objectclass
  - ou
  - authorityRevocationList
  - caCertificate
  - certificateRevocationList
  - crossCertificatePair
3. Add the following entry (modified per your deployment) to Directory Server.
```
dn: ou=1CA-AC1,dc=sun,dc=com
objectClass: top
objectClass: organizationalunit
objectClass: iplanet-am-managed-ca-container
ou: 1CA-AC1
```
You will publish the appropriate CRL to the entry created in the last step.

Publish the appropriate CRL to the corresponding LDAP entry.

This part can be done automatically by OpenSSO Enterprise or manually. If the certificate being validated has a CRL Distribution Point Extension value, the publishing of the CRL is done automatically. If the certificate being validated has an IssuingDistributionPointExtension value, the initial publishing of the CRL must be done manually but future updates are done in runtime. If the certificate being validated has neither of these values, updates must be done manually at all time. See To Manually Populate a Directory Server with a Certificate Revocation List for information on manual population.

Configure OpenSSO Enterprise in the console to point to the instance of Directory Server designated as the CRL repository.
1. In the OpenSSO Enterprise Console, click the Configuration tab.
2. Click Servers and Sites tab.
3. Click the Server Name.
4. Click Security tab.
5. Click Inheritance Settings.
6. Uncheck the following properties:
  - LDAP Search Base DN
  - LDAP Server Bind Password
  - LDAP Server Bind Username
  - LDAP Server Host Name
  - LDAP server port number
  - Search Attributes
  - SSL Enabled
7. Click Save and then Back to Server Profile.
8. Click Certificate Revocation List Caching.
9. Configure the following attributes. See Certificate Revocation List Caching in Sun OpenSSO Enterprise 8.0 Administration Reference for definitions of the properties:
  - LDAP Server Host Name
  - LDAP Server Port Number
  - SSL Enabled
  - LDAP Server Bind User Name
  - LDAP Server Bind Password
  - LDAP Search Base DN
  - Search Attributes
10. Click Save.
11. Restart the web container.

Import all the certificate authority certificates into the cacerts keystore under the java.home/jre/lib/secure directory using the keytool utility.

Certificates must be imported as trustedcacert. More information on keytool can be found at http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html.

To Manually Populate a Directory Server with a Certificate Revocation List

Use your browser to get the initial CRL from the certificate authority manually.

Save the initial CRL file in the binary DER format to your local machine.

Convert the DER file to the text-based PEM format and finally LDAP Data Interchange Format (LDIF) using the following command:

ldif -b certificaterevocationlist;binary crl.ldif

Note –

The ldif command is available in your Directory Server installation.

The crl.ldif file contains text similar to the following:

certificaterevocationlist;binary:: MIH7MIGmMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBA
  YTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUE
  tJMRwwGgYDVQQDExNEb0QgQ2xhc3MgMyBSb290IENBFw0wNzA1MDExNDMzMDNaFw0wNzA1MDExNz
  UzMDNaMBQwEgIBTxcNMDcwNDI3MTY1NzMzWjANBgkqhkiG9w0BAQUFAANBADUd7lBe7JeQKQnKCK
  GddnsCXqii7EitbPuYT55M4Nn3qBgPFSG8bX9H5XBGTB4iofb3h0Y9DCqe10vc8dBM0

Do one of the following to define the LDAP entry in which the CRL will be stored.

For an existing entry, specify the DN in the LDIF file.

# entry-id: famouseCA dn: CN=famouseCA,ou=People,dc=sun,dc=com 
certificaterevocationlist;binary:: MIH7MIGmMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBA
  YTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUE
  tJMRwwGgYDVQQDExNEb0QgQ2xhc3MgMyBSb290IENBFw0wNzA1MDExNDMzMDNaFw0wNzA1MDExNz
  UzMDNaMBQwEgIBTxcNMDcwNDI3MTY1NzMzWjANBgkqhkiG9w0BAQUFAANBADUd7lBe7JeQKQnKCK
  GddnsCXqii7EitbPuYT55M4Nn3qBgPFSG8bX9H5XBGTB4iofb3h0Y9DCqe10vc8dBM0

For a new entry, specify the DN and object classes in the LDIF file.

# entry-id: tester200
dn: CN=famouseCA,ou=People,dc=sun,dc=com
sn: famouseCA
cn: famouseCA
employeeNumber: 1001
telephoneNumber: 555-555-5555
postalAddress: 555 Test Drive
iplanet-am-modifiable-by: cn=Top-level Admin Role,dc=iplanet,dc=com
mail: famouseCA@test.com
givenName: Test
inetUserStatus: Active
uid: tester200
objectClass: iplanet-am-user-service
objectClass: inetAdmin
objectClass: iPlanetPreferences
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: iplanet-am-managed-person
objectClass: inetuser
objectClass: top
userPassword: {SSHA}E3TJ4DT7IoOLETVny1ktxUGWNTpBYq8tj3C1Sg==
creatorsName: cn=puser,ou=dsame users,dc=iplanet,dc=com
modifiersName: cn=puser,ou=dsame users,dc=iplanet,dc=com
createTimestamp: 20031125043253Z
modifyTimestamp: 20031125043253Z
certificaterevocationlist;binary:: MIH7MIGmMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBA
  YTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUE
  tJMRwwGgYDVQQDExNEb0QgQ2xhc3MgMyBSb290IENBFw0wNzA1MDExNDMzMDNaFw0wNzA1MDExNz
  UzMDNaMBQwEgIBTxcNMDcwNDI3MTY1NzMzWjANBgkqhkiG9w0BAQUFAANBADUd7lBe7JeQKQnKCK
  GddnsCXqii7EitbPuYT55M4Nn3qBgPFSG8bX9H5XBGTB4iofb3h0Y9DCqe10vc8dBM0G8=

Run one of the following ldapmodify commands based on whether you are adding the LDIF file to an existing entry or creating a new entry.
- To add a CRL to an existing LDAP entry (using an LDIF file with a specified DN), use the following command:
```
ldapmodify -r -h Directory Server_host -p Directory Server_port 
-f ldif-file -D cn=Directory Manager -w password
```
- To add a CRL to a new LDAP entry (using an LDIF file with a specified DN and object classes), use the following command:
```
ldapmodify -a -h Directory Server_host -p Directory Server_port 
-f ldif-file -D cn=Directory Manager -w password
```

To Enable Certificate Revocation List Checking for SAMLv2

In the OpenSSO Enterprise Console, click the Configuration tab.

Click the Global sub tab.

Click SAMLv2 Service Configuration.

Check the box for XML Signing Certificate Validation.

Check the box for CA Certificate Validation. This step is optional.

Click Save.

Restart the web container.

SAMLv2 IDP Discovery Service

In deployments having more than one identity provider, service providers need to determine which identity provider a principal uses with the Web Browser SSO profile. To allow for this, the SAML v2 IDP Discovery Service relies on a cookie written in a domain that is common to all identity providers and service providers in a circle of trust. This predetermined domain is known as the common domain, and the cookie containing the list of identity providers to chose from is known as the common domain cookie.

The Reader and Writer URLs, used by the SAML v2 IDP Discovery Service, are defined when configuring the circle of trust. When a user requests access from a service provider, and an entity identifier for an identity provider is not received in the request, the service provider redirects the request to the common domain's SAML v2 IDP Discovery Service Reader URL to retrieve the identity provider's entity identifier. If more then one identity provider entity identifier is returned, the last entity identifier in the list is the one to which the request is redirected. Once received, the identity provider redirects to the Discovery Service Writer URL to set the common domain cookie using the value defined in the installation configuration properties file. The following section describes the procedure for setting up and testing the Identity Provider Discovery Service.

For steps to deploy the IDP Discovery Service, see Chapter 10, Deploying the Identity Provider (IDP) Discovery Service, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Bootstrapping the Liberty ID-WSF with SAML v2

SAML v2 can be used to bootstrap into the Liberty Alliance Project Identity Web Services Framework (Liberty ID-WSF) version 1.1. For example, a service provider communicating with the SAML v2 specifications might want to communicate with web services based on the Liberty ID-WSF regarding a principal. To do this, the SAML v2 Assertion returned to the service provider must contain a Discovery Service endpoint. The service provider than acts as a web services consumer, using the value included within the Endpoint tag to bootstrap the Discovery Service. This then allows access to other Liberty ID-WSF services.

A sample SAMLv2 assertion is reproduced below. Note the SAML v2 security token stored in the Discovery Service resource offering: urn:liberty:security:2003-08:null:SAML. Both are stored within the attribute statement.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" 
ID="s21bdfd298f332ef2ada1d4fd00bab21c0f64cc90a" 
IssueInstant="2007-03-27T08:25:26Z">
<saml:Issuer>http://example.com</saml:Issuer>
<saml:Subject>
<saml:NameID NameQualifier="http://example.com" 
  SPNameQualifier="http://isdev-2.red.iplanet.com" Format=
  "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
  HuCJIy9v5MdrjJQOgsuT4NWmVUl3</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2007-03-27T08:35:26Z" 
  InResponseTo="s20711ed113989a9bff544f61c700d0bd0a08b78fd" 
  Recipient="http://isdev-2.red.iplanet.com:58080/
  opensso/Consumer/metaAlias/sp"  >
  </saml:SubjectConfirmationData>
  </saml:SubjectConfirmation>
  </saml:Subject>
<saml:Conditions NotBefore="2007-03-27T08:25:26Z" 
  NotOnOrAfter="2007-03-27T08:35:26Z">
<saml:AudienceRestriction>
<saml:Audience>http://isdev-2.red.iplanet.com</saml:Audience>
  </saml:AudienceRestriction>
  </saml:Conditions>
<saml:AuthnStatement AuthnInstant="2007-03-27T08:19:24Z" 
  SessionIndex="s234f01958bf364aff26829d9d9846ba51afc2b201">
  <saml:AuthnContext>
  <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:
  2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
  </saml:AuthnContext>
  </saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="offerings" NameFormat="urn:liberty:disco:2003-08">
<saml:AttributeValue xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<ResourceOffering xmlns="urn:liberty:disco:2003-08">
<ResourceID xmlns="urn:liberty:disco:2003-08">http://example.iplanet.com
  /aWQ9aWRwLG91PXVzZXIsZGM9aXBsYW5ldCxkYz1jb20sYW1zZGtkbj11aWQ9aWRwLG91PXBlb3BsZ
  SxkYz1pcGxhbmV0LGRjPWNvbQ%3D%3D</ResourceID>
<ServiceInstance xmlns="urn:liberty:disco:2003-08">
<ServiceType>urn:liberty:disco:2003-08</ServiceType>
<ProviderID>http://mach1.red.com</ProviderID>
<Description xmlns="urn:liberty:disco:2003-08" 
  id="sf6a6d3dcc16e729eea0d7e5587a5ff27f234f991">
<SecurityMechID>urn:liberty:security:2003-08:null:SAML
  </SecurityMechID>
<CredentialRef>s5dc88819de075e4e9c8db3deb8b46d4d8758b4b901
  </CredentialRef>
<Endpoint>http://mach1.red.com:58080/opensso/Liberty/disco
  </Endpoint></Description>
  </ServiceInstance></ResourceOffering></saml:AttributeValue></saml:Attribute>
<saml:Attribute Name="credentials" NameFormat="urn:liberty:disco:2003-08">
<saml:AttributeValue xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Assertion  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
  MajorVersion="1" MinorVersion="1" 
  AssertionID="s5dc88819de075e4e9c8db3deb8b46d4d8758b4b901" Issuer=
  "http://mach1.red.com" IssueInstant="2007-03-27T08:25:26Z" >
<sec:ResourceAccessStatement xmlns:sec="urn:liberty:sec:2003-08">
<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:NameIdentifier NameQualifier="http://isdev-2.red.com" 
  Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
  HuCJIy9v5MdrjJQOgsuT4NWmVUl3</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sendervouches
  </saml:ConfirmationMethod>
  </saml:SubjectConfirmation>
  </saml:Subject>
<ResourceID xmlns="urn:liberty:disco:2003-08">http://example.com/
aWQ9aWRwLG91PXVzZXIsZGM9aXBsYW5ldCxkYz1jb20sYW1zZG
tkbj11aWQ9aWRwLG91PXBlb3BsZSxkYz1pcGxhbmV
0LGRjPWNvbQ%3D%3D</ResourceID>
<sec:ProxySubject xmlns:sec="urn:liberty:sec:2003-08">
<saml:NameIdentifier xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
Format="urn:liberty:iff:nameid:entityID">http://isdev-2.red.com
  </saml:NameIdentifier>
<saml:SubjectConfirmation xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
  </saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><KeyName>CN=sun-unix, OU=Sun 
  Access Manager, O=Sun, C=US</KeyName><KeyValue><RSAKeyValue><Modulus>AOA/2kpfKFWvRXOMbrmTlKe102ibw/
  aTd3HBVgI8cHsywww8M1J0X+vJvvk6eabTNWY5jBfTo9i1bC4AXXoRlxgsE/
  6Uq5+6NGrd+iwfvj25x8HzHX8LrJ+7EzlGVsKO
  M+A3vTP0tCkmYE4jatZbWlRoto0wyInP2wMFdKPrmYWL</Modulus>
<Exponent>AQAB</Exponent></RSAKeyValue>
  </KeyValue></KeyInfo></saml:SubjectConfirmation>
  </sec:ProxySubject><sec:SessionContext xmlns:sec="urn:liberty:sec:2003-08" AuthenticationInstant=
  "2007-03-27T08:25:26Z" AssertionIssueInstant="2007-03-27T08:25:26Z">
<sec:SessionSubject xmlns:sec="urn:liberty:sec:2003-08">
<saml:NameIdentifier xmlns:saml="urn:oasis:names:tc:SAML:1.0:
  assertion" NameQualifier="http://isdev-2.red.com" 
  Format="urn:oasis:names:tc:SAML:
  2.0:nameid-format:persistent">HuCJIy9v5MdrjJQOgsuT4NWmVUl3
  </saml:NameIdentifier>
<saml:SubjectConfirmation xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:2.0:cm:bearer</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
<lib:IDPProvidedNameIdentifier  xmlns:lib="http://projectliberty.org/
  schemas/core/2002/12" 
  NameQualifier="http://example.com" Format="urn:oasis:names:tc:SAML:2.0:
  nameid-format:persistent"  >HuCJIy9v5MdrjJQOgsuT4NWmVUl3
  </lib:IDPProvidedNameIdentifier>
  </sec:SessionSubject>
<sec:ProviderID>http://mach1.red.com</sec:ProviderID>
  <lib:AuthnContext xmlns:lib="urn:liberty:iff:2003-08"><lib:AuthnContextClassRef>urn:oasis:
  names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</lib:AuthnContextClassRef>
  <lib:AuthnContextStatementRef>http://www.projectliberty.org/schemas/authctx/classes/
  Password</lib:AuthnContextStatementRef></lib:AuthnContext></sec:SessionContext>
  </sec:ResourceAccessStatement>
<saml:AuthenticationStatement xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
  AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" 
  AuthenticationInstant="2007-03-27T08:19:24Z">
<saml:Subject>
<saml:NameIdentifier Format="urn:liberty:iff:nameid:entityID">
  http://isdev-2.red.com</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
  </saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><KeyName>CN=sun-unix, OU=Sun 
  Access Manager, O=Sun, C=US</KeyName><KeyValue><RSAKeyValue><Modulus>AOA/2kpfKFWvRXOMbrmTlKe102ibw/
  aTd3HBVgI8cHsywww8M1J0X+vJvvk6eabTNWY5jBfTo9i1bC4AXXoRlxgsE/6Uq
  5+6NGrd+iwfvj25x8HzHX8LrJ+7EzlGVsKOM+
  A3vTP0tCkmYE4jatZbWlRoto0wyInP2wMFdKPrmYWL</Modulus>
<Exponent>AQAB</Exponent>
  </RSAKeyValue>
  </KeyValue></KeyInfo></saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#s5dc88819de075e4e9c8db3deb8b46d4d8758b4b901">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>td1CqmbWC5eMXCK6IFhzZxn3GJg=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
YJ4g+jV5KIQRpkI9jlsZMbKx9lBhEB5ngB8NrH5nPh8+XFTK2gPZNzovOYOzxlznuxxbvC3A4rpg
UoSeE3N+oE4sl5KnY1GewFgjckAdeWafcLhGd9O68A+9nqMnRW/5fR9mnbk9eqZO8zx2bO8toiWi
pQCTU5XcDYkCNb8LgFs=
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
MIICOTCCAeOgAwIBAgIBEjANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP
cmVkLmlwbGFuZXQuY29tMRwwGgYDVQQDExNDZXJ0aWZpY2F0ZSBNYW5hZ2VyMB4XDTA1MDYwMjE3
NTkxOFoXDTA2MDYwMjE3NTkxOFowVzELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA1N1bjEnMCUGA1UE
CxMeU1VOIEphdmEgU3lzdGVtIEFjY2VzcyBNYW5hZ2VyMREwDwYDVQQDEwhzdW4tdW5peDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4D/aSl8oVa9Fc4xuuZOUp7XTaJvD9pN3ccFWAjxwezLD
DDwzUnRf68m++Tp5ptM1ZjmMF9Oj2LVsLgBdehGXGCwT/pSrn7o0at36LB++PbnHwfMdfwusn7sT
OUZWwo4z4De9M/S0KSZgTiNq1ltaVGi2jTDIic/bAwV0o+uZhYsCAwEAAaNoMGYwEQYJYIZIAYb4
QgEBBAQDAgZAMA4GA1UdDwEB/wQEAwIE8DAfBgNVHSMEGDAWgBQqOASyzZ41LergF+cSQN1Gokpa
XjAgBgNVHREEGTAXgRVoZW5nLW1pbmcuaHN1QHN1bi5jb20wDQYJKoZIhvcNAQEEBQADQQDKxdPy
821aQRVZ0wLqa6LBYZCUcZD5AMvzl3EylwtniHmzPtOeZe4NmFj7qQziSb1H57NSkiwKaLZ7Mt6F
jaUU
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature></saml:Assertion>
</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion>

Following are the procedures to enable bootstrapping of the Liberty ID-WSF Discovery Service using SAML v2.

To Enable an Identity Provider for SAML v2 Bootstrapping of Liberty ID-WSF

If metadata for the identity provider you are configuring has not yet been imported, or signing and encryption certificate aliases have not been configured in the for the existing identity provider metadata, create the identity provider in the OpenSSO Enterprise console or with the ssoadm command line utility. See Creating an Entity.

In the OpenSSO Enterprise Console, click the Federation tab.

Click the hosted Identity Provider you wish to edit.

Check Discovery Bootstrapping Enabled check box.

Click Save.

Go to the Configuration tab.

Click the Servers and Sites tab.

Click Default Server Settings.

Click the Advanced tab.

If the com.sun.identity.liberty.ws.util.providerManagerClass property does not exist in the Advanced attribute table, add it and define the following value for it:

com.sun.identity.liberty.ws.util.providerManagerClass = com.sun.identity.saml2.plugins.SAML2ProviderManager

Note –
By default, this property has no value. In this case, Liberty ID-WSF 1.1 works with ID-FF providers. After you change this value, ID-WSF 1.1 works with SAMLv2 providers but not ID-FF providers. To switch back to ID-FF providers, delete the attribute from the Advanced attribute table.

Click Save.

Restart the web container.

To Enable a Service Provider for SAML v2 Bootstrapping of Liberty ID-WSF

In the OpenSSO Enterprise Console, click the Federation tab.

Click the hosted Service Provider you wish to configure.

Click the Assertion Processing tab.

In the Attribute Map attribute, add the following value:

urn:liberty:disco:2003-08:DiscoveryResourceOffering=urn:liberty:disco:2003-08:DiscoveryResourceOffering

Click Save.

Retrieving SAMLv2 Bootstrapping of Liberty ID-WSF from the WSC

You can use the following API to retrieve the Discovery Service bootstrap resource offering and included security token from the web services client:

ResourceOffering SAML2SDKUtil.getDiscoveryBootStrapResourceOffering(
HttpServletRequest request)

List SAML2SDKUtil.getDiscoveryBootStrapCredentials(
HttpServletRequest request)

For more information, see the Sun OpenSSO Enterprise 8.0 Java API Reference.

SAMLv2 Operations

POST Binding with Single Sign-on and Single Logout

Creating Affiliations

Requesting Attribute Values Using a SAMLv2 Assertion

Requesting a SAMLv2 Assertion

Requesting a SAMLv2 Assertion for Authentication Context

To Configure for Authentication Context Queries

Encoding Artifacts

Managing SAMLv2 Name Identifiers

idpMNIRequestInit.jsp

spMNIRequestInit.jsp

Mapping SAMLv2 Name Identifiers

Enhanced Client and Proxy

To Configure for ECP on the Identity Provider Side

To Configure for ECP on the Service Provider Side (Optional)

Formatting Name Identifiers

Configuring SAMLv2 Single Sign-on without Service Provider User Accounts

To Use the Transient Name Identifier

To Federate Disparate Accounts with Auto Federation

To Map Attributes to anonymous User Account

To Achieve Single Sign-on Without Data Store Writes

Auto-creation of User Accounts

To Enable Auto-creation

Before You Begin

Using Non-Default Federation Attributes

To Store Federation Information in Existing Attributes

Enabling XML Signing and Encryption

Securing SOAP Binding

Basic Authentication

Secure Socket Layer/Transport Layer Security

Server Certificate Authentication

Client Certificate Authentication

Load Balancing

To Enable Load Balancer Support

Access Control

To Enable Access Control Using Agents

Certificate Revocation List Checking

To Set Up for Certificate Revocation List Checking

Before You Begin

To Manually Populate a Directory Server with a Certificate Revocation List

To Enable Certificate Revocation List Checking for SAMLv2

SAMLv2 IDP Discovery Service

Bootstrapping the Liberty ID-WSF with SAML v2

To Enable an Identity Provider for SAML v2 Bootstrapping of Liberty ID-WSF

To Enable a Service Provider for SAML v2 Bootstrapping of Liberty ID-WSF

Retrieving SAMLv2 Bootstrapping of Liberty ID-WSF from the WSC

`idpMNIRequestInit.jsp`

`spMNIRequestInit.jsp`

To Map Attributes to `anonymous` User Account