Sun Java System SAML v2 Plug-in for Federation Services User's Guide

Chapter 4 Configuring Specialized Interactions

The SAML v2 Plug-in for Federation Services can be configured to support many specialized interactions. The use cases described in this chapter give you a general idea of how the SAML v2 Plug-in for Federation Services can be used.

This chapter covers the following topics:

Single Sign-on

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.

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=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 JavaServer Pages.

To Configure Single Sign-on without Service Provider 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 AttributeStatement 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.

Export the identity provider's current extended metadata configuration to a file.

saml2meta [-i staging-directory] export -u amadmin -w password -e IDP-entityID -x IDP-extended-XML-file-name

Edit attributeMap in the exported extended metadata configuration file.

attributeMap 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:
```
<Attribute name="attributeMap">
<Value>mail=mail</Value>
<Value>employeeNumber=employeeNumber</Value>
</Attribute>
```

Remove the identity provider's current extended metadata configuration.

saml2meta [-i staging-directory] delete -u amadmin -w password -e IDP-entityID -c

Import the identity provider's modified extended metadata configuration file.

saml2meta [-i staging-directory] import -u amadmin -w password -x IDP-extended-XML-file-name

Restart the web container.

Export the service provider's current extended metadata configuration to a file.

saml2meta [-i staging-directory] export -u amadmin -w password -e SP-entityID -x SP-extended-XML-file-name

Edit the following attributes in the exported extended metadata configuration file.
- transientUser will take a value of one of the existing transient user identifiers on the service provider side, for example, anonymous.
- attributeMap 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:
```
<Attribute name="attributeMap">
<Value>mail=mail</Value>
<Value>employeeNumber=employeeNumber</Value>
</Attribute>
```

Remove the service provider's current extended metadata configuration.

saml2meta [-i staging-directory] delete -u amadmin -w password -e SP-entityID -c

Import the service provider's modified extended metadata configuration file.

saml2meta [-i staging-directory] import -u amadmin -w password -x SP-extended-XML-file-name

Restart the web container.

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. For more information on the single sign-on URL, see JavaServer Pages.

Auto-Federation

The auto-federation feature will automatically federate a user's disparate provider accounts based on a common attribute defined in the interacting provider's metadata. (It is also referred to as attribute federation.) This common attribute, when exchanged in a single sign-on assertion, would identify the user at both provider sites and automatically create the appropriate federations. The following sections describe procedures for auto-federation.

Note –

Auto-federation with the transient name identifier can also be configured as described in To Configure Single Sign-on without Service Provider User Account.

To Enable Auto-Federation

Before You Begin

You must configure the attribute mapper on the identity provider side to include the common attribute as part of the AttributeStatement. You must also configure the attribute mapper on the service provider side to use the common attribute to find the user.

Note –

You can also configure the account mapper on the service provider side to map all users to a single user (such as anonymous).

Export the identity provider's current extended metadata configuration to a file.

saml2meta [-i staging-directory] export -u amadmin -w password -e IDP-entityID -x IDP-extended-XML-file-name

Edit the following attributes in the exported extended metadata configuration file.
- autofedEnabled takes a value of true.
- autofedAttribute defines the common attribute. For example, <Value>employeeNumber</Value>
- attributeMap 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:
```
<Attribute name="attributeMap">
<Value>employeeNumber=employeeNumber</Value>
</Attribute>
```

Remove the identity provider's current extended metadata configuration.

saml2meta [-i staging-directory] delete -u amadmin -w password -e IDP-entityID -c

Import the identity provider's modified extended metadata configuration file.

saml2meta [-i staging-directory] import -u amadmin -w password -x IDP-extended-XML-file-name

Restart the web container.

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

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

Following the auto-federation, two SAML v2 attributes and corresponding values are written to the user's data store entry.

To Configure 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.

Export the identity provider's current extended metadata configuration to a file.

saml2meta [-i staging-directory] export -u amadmin -w password -e IDP-entityID -x IDP-extended-XML-file-name

Edit the following attributes in the exported extended metadata configuration file.
- autofedEnabled takes a value of true.
- autofedAttribute defines the common attribute on the identity provider side. For example, mail.
- attributeMap 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>
```

Remove the identity provider's current extended metadata configuration.

saml2meta [-i staging-directory] delete -u amadmin -w password -e IDP-entityID -c

Import the identity provider's modified extended metadata configuration file.

saml2meta [-i staging-directory] import -u amadmin -w password -x IDP-extended-XML-file-name

Restart the web container.

Export the service provider's current extended metadata configuration to a file.

saml2meta [-i staging-directory] export -u amadmin -w password -e SP-entityID -x SP-extended-XML-file-name

Edit the following attributes in the exported extended metadata configuration file.
- transientUser takes a null value.
- autofedEnabled takes a value of true.
- autofedAttribute defines the common attribute. For example, mail.
- attributeMap 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:
```
<Attribute name="attributeMap">
<Value>mail=mail</Value>
</Attribute>
```

Remove the service provider's current extended metadata configuration.

saml2meta [-i staging-directory] delete -u amadmin -w password -e SP-entityID -c

Import the service provider's modified extended metadata configuration file.

saml2meta [-i staging-directory] import -u amadmin -w password -x SP-extended-XML-file-name

Restart the web container.

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 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 Access Manager 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.

Export the identity provider's current extended metadata configuration to a file.

saml2meta [-i staging-directory] export -u amadmin -w password -e IDP-entityID -x IDP-extended-XML-file-name

Edit the following attributes in the exported extended metadata configuration file.
- autofedEnabled takes a value of true.
- autofedAttribute defines the common attribute. For example, <Value>employeeNumber</Value>
- attributeMap 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:
```
<Attribute name="attributeMap">
<Value>employeeNumber=employeeID</Value>
</Attribute>
```

Remove the identity provider's current extended metadata configuration.

saml2meta [-i staging-directory] delete -u amadmin -w password -e IDP-entityID -c

Import the identity provider's modified extended metadata configuration file.

saml2meta [-i staging-directory] import -u amadmin -w password -x IDP-extended-XML-file-name

Restart the web container.

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

Enable Dynamic Profile Creation using the Access Manager console.
1. Log in to the Access Manager 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 Access Manager.

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

For more information, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

Using Non-Default Federation Attributes

If Access Manager or Federation Manager 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

Modify the values of the following properties in AMConfig.properties to reflect the existing attributes to which you want federation information written:
- com.sun.identity.saml2.nameidinfo.attribute
- com.sun.identity.saml2.nameidinfokey.attribute
Note –
AMConfig.properties is located in the /etc/opt/product-directory/config directory in Access Manager and in the /staging-directory/web-src/WEB-INF/classes directory in Federation Manager.

Restart the web container.

Federation information will now be written to the specified attributes.

Enabling XML Signing and Encryption

This section contains the procedure to enable XML signing and encryption.

Caution –

If you are modifying your organization's metadata remember to contact all providers in the circle of trust with the new metadata.

To Enable XML Signing and Encryption

In AMConfig.properties, set com.sun.identity.jss.donotInstallAtHighestPriority equal to true.

Note –
AMConfig.properties is located in the /etc/opt/product-directory/config directory in Access Manager and in the /staging-directory/web-src/WEB-INF/classes directory in Federation Manager.

Follow the instructions in the XMLSIG sample to setup a keystore and import the signing and encryption certificates to the keystore.

In Access Manager, the sample is located in the /AccessManager-base/product-directory/samples/saml/xmlsig directory. In Federation Manager, the sample is located in the /FederationManager-base/SUNWam/fm/samples/saml/xmlsig directory.

Note –
The certificate alias assigned during this process will be used in the following steps to identify the certificate.

Regenerate the metadata files so that they include the signing and encryption key information.
- For identity provider metadata, run the following command:
  
  saml2meta template [-i war-staging] -u admin -w admin-password -d idp-metaAlias -b idp-signing-key-alias -g idp-encryption-key-alias -e idp-entityID -m standard-XML-file-name -x extended-XML-file-name
  
  For example:
  
  saml2meta template -u amadmin -w 11111111 -d /idp -b test -g test -e idp.sun.com -m idpMeta.xml -x idpExt.xml
- For service provider metadata, run the following command:
  
  saml2meta template [-i war-staging] -u admin -w admin-password -s sp-metaAlias -a sp-signing-key-alias -f sp-encryption-key-alias -e sp-entityID -m standard-XML-file-name -x extended-XML-file-name
  
  For example:
  
  saml2meta template -u amadmin -w 11111111 -s /idp -a test -f test -e sp.sun.com -m spMeta.xml -x spExt.xml

Enable the appropriate XML signing and encryption features by modifying the generated metadata files.

Note –
XML signing is required for the Web Browser POST Profile.

You can turn on XML signing and encryption features by changing the value of the following attributes to true:
- Identity Provider Standard Metadata Configuration File Attribute
  - wantAuthnRequestsSigned
- Service Provider Standard Metadata Configuration File Attributes
  - AuthnRequestsSigned
  - WantAssertionsSigned
- Identity Provider Extended Metadata Configuration File Attributes
  - wantNameIDEncrypted
  - wantArtifactResolveSigned
  - WantLogoutRequestSigned
  - WantLogoutResponseSigned
  - WantMNIRequestSigned
  - WantMNIResponseSigned
- Service Provider Extended Metadata Configuration File Attributes
  - wantAttributeEncrypted
  - wantAssertionEncrypted
  - wantNameIDEncrypted
  - wantArtifactResponseSigned
  - WantLogoutRequestSigned
  - WantLogoutResponseSigned
  - WantMNIRequestSigned
  - WantMNIResponseSigned

Remove the hosted identity provider metadata by running the following command:

saml2meta delete -u amadmin -w admin-password -e idp-entityID

Import the new hosted identity provider metadata by running the following command:

saml2meta import -u amadmin -w admin-password -m standard-XML-file-name -x extended-XML-file-name -t COT-name

Remove the remote service provider metadata by running the following command:

saml2meta delete -u amadmin -w admin-password -e sp-entityID

Get the new remote service provider metadata.

The instructions in this step assume a testing environment where you are in control of both the identity provider server and the service provider server.
1. Copy spMeta.xml and spExtended.xml from the service provider machine.
2. Change hosted="1" to hosted="0" in spExtended.xml.

Import the new remote service provider metadata by running the following command:

saml2meta import -u amadmin -w admin-password -m standard-XML-file-name -x extended-XML-file-name -t COT-name

Remove the remote identity provider metadata by running the following command:

saml2meta delete -u amadmin -w admin-password -e idp-entityID

Get the new remote identity provider metadata.

The instructions in this step assume a testing environment where you are in control of both the identity provider server and the service provider server.
1. Copy idpMeta.xml and idpExtended.xml from the identity provider machine.
2. Change hosted="1" to hosted="0" in idpExtended.xml.

Import the new remote identity provider metadata by running the following command:

saml2meta import -u amadmin -w admin-password -m standard-XML-file-name -x extended-XML-file-name -t COT-name

Remove the hosted service provider metadata by running the following command:

saml2meta delete -u amadmin -w admin-password -e sp-entityID

Import the new hosted service provider metadata by running the following command:

saml2meta import -u amadmin -w admin-password -m standard-XML-file-name -x extended-XML-file-name -t COT-name

Restart your web container.

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.

Table 4–1 Securing SOAP Endpoint with Basic Authentication


Attribute	Description
`basicAuthOn`	Establishes that the SOAP endpoint is using basic authentication. Takes a value of `true` or `false`.
`basicAuthUser`	Defines the user allowed access to the protected SOAP endpoint in the original SAML v2 entity.
`basicAuthPassword`	Defines an encrypted password for the user. The password is encrypted using `ampassword` on the partner side. For information on `ampassword`, see Sun Java System Access Manager 7 2005Q4 Administration Guide.

To modify the metadata, you must first export it to a file. Once you've modified the values of the applicable attributes, the metadata must be reloaded using the saml2meta command and the web container must be restarted. For more information, see The saml2meta Command-line Reference.

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 certificate(s).
`-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 Authentication.
`-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 Access Manager and Federation Manager 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 Access Manager and Federation Manager and follow the documentation to set up a load balancer.

Load balancing information for Access Manager can be found in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.

Install the SAML v2 Plug-in for Federation Services on any machines acting as an identity provider or a service provider.

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 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 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 and Roles

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.

Install the SAML v2 Plug-in for Federation Services on the identity provider.

Install the SAML v2 Plug-in for Federation Services on the service provider.

Note –
The service provider must be an instance of Access Manager because Federation Manager does not currently support policy.

Install the Sun Java System Policy Agents 2.2 to protect the service provider configured on the instance of Access Manager.

For more information, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.

Modify com.sun.am.policy.am.login.url in AMAgent.properties so that 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.

com.sun.am.policy.am.login.url=SP-protocol://SP-host:SP-port/service-deploy-uri/
saml2/jsp/spSSOInit.jsp?NameIDFormat=transient&metaAlias=SP-metaAlias&
idpEntityID=IDP_EntityID

For example:

com.sun.am.policy.am.login.url=http://moonriver.red.sun.com:58080/
amserver/saml2/jsp/spSSOInit.jsp?NameIDFormat=transient&metaAlias=/sp&
idpEntityID=sunriver.central.sun.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 Access Manager or Federation Manager. An example value might be http://host:port/amserver/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 Configure Single Sign-on Without Data Store Writes.

To test, we 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 SessionProperty condition on the service provider instance of Access Manager.
1. Log in to the Access Manager 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 SessionProperty 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, we will use employeenumber.
16. Add the match value to the Values field and click Add.
  
  To test, we will 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 the Sun Java System Access Manager 7 2005Q4 Administration Guide.

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 reason(s) 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 Access Manager or Federation Manager 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 AMConfig.properties. 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.

Note –

The LDAP directory which acts as the CRL repository is also configured in AMConfig.properties.

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 Java System 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 Access Manager or Federation Manager schema is stored or it can be standalone. The Java Development Kit (JDK) must be version 1.5 or higher.

Note –

If enabling this feature on an instance of Access Manager, it must be Access Manager version 7.0sp5 and above.

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 Access Manager or Federation Manager 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 the following properties in AMConfig.properties to point to the instance of Directory Server designated as the CRL repository.
- com.sun.identity.saml2.crl.cache.directory.host defines the LDAP directory's host name.
- com.sun.identity.saml2.crl.cache.directory.port defines the LDAP directory's port number.
- com.sun.identity.saml2.crl.cache.directory.ssl takes a vale of TRUE or FALSE.
- com.sun.identity.saml2.crl.cache.directory.user defines the DN of the user with permission to bind to the LDAP directory.
- com.sun.identity.saml2.crl.cache.directory.password defines the encrypted password for the bind user. Use ampassword for the encryption. SeeChapter 2, The ampassword Command Line Tool, in Sun Java System Access Manager 7.1 Administration Reference for more information.
- com.sun.identity.saml2.crl.cache.directory.searchloc defines the base DN from where the search will begin.
- com.sun.identity.saml2.crl.cache.directory.searchattr defines the component of the root certificate's subjectDN (issuer) that will be used to retrieve the CRL from LDAP directory. The value is a single string as in cn.
  
  Note –
  All root certificate authorities must use the same search attribute.
  
  com.sun.identity.saml2.crl.cache.directory.password defines the password for the bind user. This actually need to be the encrypted password of the bind user, customer need to use ampassword to encrypt the password before putting values here.

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 < famouseCA.crl > 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
```

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 SAML v2 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://hengming.red.iplanet.com</saml:Issuer>
<saml:Subject>
<saml:NameID NameQualifier="http://hengming.red.iplanet.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/
  amserver/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://hengming.red.iplanet.com
  /aWQ9aWRwLG91PXVzZXIsZGM9aXBsYW5ldCxkYz1jb20sYW1zZGtkbj11aWQ9aWRwLG91PXBlb3BsZ
  SxkYz1pcGxhbmV0LGRjPWNvbQ%3D%3D</ResourceID>
<ServiceInstance xmlns="urn:liberty:disco:2003-08">
<ServiceType>urn:liberty:disco:2003-08</ServiceType>
<ProviderID>http://hengming.red.iplanet.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://hengming.red.iplanet.com:58080/amserver/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://hengming.red.iplanet.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.iplanet.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://hengming.red.iplanet.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.iplanet.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 Java System 
  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.iplanet.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://hengming.red.iplanet.com" Format="urn:oasis:names:tc:SAML:2.0:
  nameid-format:persistent"  >HuCJIy9v5MdrjJQOgsuT4NWmVUl3
  </lib:IDPProvidedNameIdentifier>
  </sec:SessionSubject>
<sec:ProviderID>http://hengming.red.iplanet.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.iplanet.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 Java System 
  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

Before You Begin

See The saml2meta Command-line Reference for more information on the command line interface used in this procedure.

Choose one of the following options to get metadata for the appropriate identity provider.

The option you choose is dependent on where you are in the process of configuring the identity provider.
- 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 existing identity provider metadata, generate standard and extended metadata templates for the identity provider using the saml2meta command line interface.
  saml2meta template -u amadmin -w amadmin_pw -d /idp -b certificate_alias -g enc_certificate_alias -e http://host_machine -m standard_meta_filename -x extended_meta_filename
- If the identity provider metadata has been imported, and signing and encryption keys have all been configured, export the existing extended entity configuration metadata of the identity provider using the saml2meta command line interface.
  saml2meta export -u amadmin -w amadmin_pw -d /idp -e http://host_machine -x extended_meta_filename

Edit the identity provider's extended entity configuration template by changing the value of discoveryBootstrappingEnabled to true.

The extended entity configuration template is extended_meta_filename created in the previous step. If the attribute doesn't exist in the metadata, add the following lines above the ending tag </IDPSSOConfig>.
<Attribute name="discoveryBootstrappingEnabled"> <Value>true</Value> </Attribute>

(Optional) Delete the current metadata for the identity provider using the saml2meta command line interface.

The option you choose in this step is dependent on the option chosen in the first step of this procedure.
- If you choose the first option in this procedure's first step, delete the current standard and extended metadata using the saml2meta command line interface.
  saml2meta delete -u amadmin -w amadmin_pw -e http://host_machine
- If you choose the second option in this procedure's first step, delete the current extended metadata only using the saml2meta command line interface.
  saml2meta delete -u amadmin -w amadmin_pw -e http://host_machine -c

Import the new identity provider metadata.

The option you choose in this step is dependent on the option chosen in the first step of this procedure. circle_of_trust is the name of the circle of trust into which you are importing these files.
- If you choose the first option in this procedure's first step, import the standard metadata and the modified extended metadata files using the saml2meta command line interface.
  saml2meta import -u amadmin -w amadmin_pw -m standard_meta_filename -x extended_meta_filename -t circle_of_trust
- If you choose the second option in this procedure's first step, import the modified extended metadata using the saml2meta command line interface.
  saml2meta import -u amadmin -w amadmin_pw -x extended_meta_filename -t circle_of_trust

Add the following line to the end of the AMConfig.properties file to enable Liberty ID-WSF to work with SAML v2 on the identity provider.

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

Restart the web container.

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

Add the following line to the end of the AMConfig.properties file to enable Liberty ID-WSF to work with SAML v2 on the identity provider.

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

(Optional) Add the following to the class path of the web application.

/opt/SUNWam/saml2/lib/saml2.jar

This step is necessary only if the web application you are protecting is using the same Java Virtual Machine (JVM) as the instance of Access Manager or Federation Manager. In this situation, you can use the following API to retrieve the Discovery Service bootstrap resource offering and included security token
ResourceOffering SAML2SDKUtils.getDiscoveryBootStrapResourceOffering( HttpServletRequest request) List SAML2SDKUtil.getDiscoveryBootStrapCredentials( HttpServletRequest request)

Restart the web container.