Deployment Example 2: Federation Using SAML v2

Part III Setting Up the Identity Provider Site

Chapter 8 Installing the SAMLv2 Plug-in on Access Manager Servers

This chapter provides information about the following groups of tasks:

Note –

The following instructions are designed to be used on an Identity Provider Site that is already deployed and running. See 1.2 System Architecture in this manual for information about deploying the Identity Provider Site. See also 2.12 Obtaining Instructions for Deploying the Identity Provider Site in this manual.

8.1 Installing the SAMLv2 Plug-In on the Access Manager Servers

You must obtain the Sun Java System SAMLv2 Plug-in for Federation Services 1.0.

The SAMLv2 Plug-in is an auxiliary program that works with either Sun Java System Access Manager or Sun Java System Federation Manager. The plug-in incorporates a subset of features based on the Security Assertion Markup Language (SAML) version 2 specifications. When installed, the plug-in allows support for interactions based on those specifications.

You can download the plug-in from the following Sun Microsystems URL:http://sunsolve.sun.com/search/document.do?assetkey=1-21-122983-02-1.

Caution –

If you have configured an Access Manager site, be sure to remove the site ID from the Access Manager instances before installing the SAMLv2 plug-in. If the site ID exists in the Access Manager instances, SAMLv2 installation may fail.

Use the following as your checklist for installing the SAMLv2 Plug-In:

To Install the SAMLv2 Plug-In and the SAMLv2 Patch on Access Manager 1

As a root user, log in to the host Access Manager 1.

Change to the directory where you unpacked the SAMLv2 installation files. Example:

# cd /tmp/saml2
# ls
../                            
ENTITLEMENT.TXT                saml2silent
LICENSE.TXT                    samlv2-1.0-solaris-sparc.tar
README.TXT                     version
SUNWsaml2/

Modify the saml2silent file to reflect the location of the deployed Access Manager WAR file.

Make a backup copy of the saml2silent file before making any changes to it.

See changes in boldface in the following example:

############### START OF VARIABLE DEFINITIONS ###########################
 
STAGING_DIR=/opt/SUNWwbsvr/https-AccessManager-1.example.com/
is-web-apps/services
ADMINPASSWD=4m4dmin1
DEPLOY_SAMPLES=true
 
#
# SYSTEM
# AM  if SAML2 will be deployed on Access Manager
# FM  if SAML2 will be deployed on Federation Manager
# installer will auto detect if not specified.
#
 
SYSTEM=AM
 
# AM_INSTANCE
# SAML2 will be deployed on the specified AM instance.
# If it is not specified, SAML2 will be configured on the first AM instance.
#
 
AM_INSTANCE=
 
 
#
# LOAD_SCHEMA if true will load SAML2 SDS/AD schema
# DS_DIRMGRDN is the DN (distinguished name) of the directory manager,
#             the user who has unrestricted access to Directory Server.
# DS_DIRMGRPASSWD is the password for the directory manager
#
LOAD_SCHEMA=true
DS_DIRMGRDN="cn=Directory Manager"
DS_DIRMGRPASSWD=dirm4n4ger
 
 
#
# IDPDISCOVERY_ONLY set to true will only configure idpdiscovery service
# COMMON_COOKIE_DOMAIN IDP Discovery service cookie domain
# COOKIE_ENCODE  set to true, common domain cookie will be encoded.
IDPDISCOVERY_ONLY=false
COMMON_COOKIE_DOMAIN=
COOKIE_ENCODE=true
 
############### END OF VARIABLE DEFINITIONS ################################

Run the SAMLv2 installer.

# ./saml2setup install -s saml2silent

When installation is complete, you will see the following message:

Hosted entity descriptor for realm "/" was written to file 
"idpMeta.xml" successfully.
Hosted entity config for realm "/" was written to file
"idpExtended.xml" successfully.
Hosted entity descriptor for realm "/" was written to file
"spMeta.xml successfully.
Hosted entity config for realm "/" was written to file
"spExtended.xml" successfully.
Meta data created !!!

Circle of trus "samplecot" is created successfully.


Loading SAML2 schema...
The new AM server war /opt/SUNWam/amserver.war is ready for deploy!

In this deployment example, complete proceeding steps before deploying the WAR file.

Load the SAMLv2 users schema into the Access Manager users instance.

#cd /opt/SUNWam/saml2/ldif
# ldapmodify -h LoadBalancer-2.example.com -p 489 -D "cn=Directory Manager" 
-w dirm4n4ger -f saml2_sds_schema.ldif
modifying entry CN=schema

Go to the directory where you downloaded and unpacked the SAMLv2 patch installation file.

# cd /temp/saml2patch/122983-02
# ls
LEGAL_LICENSE.TXT
LICENSE.TXT
patchinfo
postbackout
postpatch
prebackout
prepatch
README.122983-01
rel_notes.html
SUNWsaml2

Run the SAMLv2 patch installer.
# cd /temp/saml2patch # patchadd -G 122983-02
When installation is complete, you will see the following message:
Patch packages installed: SUNWsaml2

Go to the directory where the SAMLv2 update script is located.
# cd /opt/SUNWam/saml2/bin

Run the update script.
# ./saml2setup update -s saml2silent
Any updates required because of the newly-installed patch are made in SAMLv2.

Restart Access Manager 1.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com # ./stop;./start
This deployment uses Sun Java System Web Server which does not require you to redeploy the Access Manager WAR file at this point. If you are using any other web container, you must redeploy the Access Manager WAR file before restarting the Access Manager 1 server.

Troubleshooting

If you must uninstall and then re-install the SAMLv2 patch for any reason, when you run the update script the script may fail. Search the saml2silent file for the string -- and delete all occurrences. The script may have inadvertently added the extraneous strings to the file.

To Install the SAMLv2 Plug-In and the SAMLv2 Patch on Access Manager 2

As a root user, log in to the host Access Manager 2.

Change to the directory where you unpacked the SAMLv2 installation files. Example:

# cd /tmp/saml2
# ls
../                            
ENTITLEMENT.TXT                saml2silent
LICENSE.TXT                    samlv2-1.0-solaris-sparc.tar
README.TXT                     version
SUNWsaml2/

Modify the saml2silent file to reflect the location of the deployed Access Manager WAR file.

Make a backup copy of the saml2silent file before making any changes to it.

See changes in boldface in the following example:

############### START OF VARIABLE DEFINITIONS ###########################
 
STAGING_DIR=/opt/SUNWwbsvr/https-AccessManager-2.example.com/
is-web-apps/services
ADMINPASSWD=4m4dmin1
DEPLOY_SAMPLES=true
 
#
# SYSTEM
# AM  if SAML2 will be deployed on Access Manager
# FM  if SAML2 will be deployed on Federation Manager
# installer will auto detect if not specified.
#
 
SYSTEM=AM
 
# AM_INSTANCE
# SAML2 will be deployed on the specified AM instance.
# If it is not specified, SAML2 will be configured on the first AM instance.
#
 
AM_INSTANCE=
 
 
#
# LOAD_SCHEMA if true will load SAML2 SDS/AD schema
# DS_DIRMGRDN is the DN (distinguished name) of the directory manager,
#             the user who has unrestricted access to Directory Server.
# DS_DIRMGRPASSWD is the password for the directory manager
#
LOAD_SCHEMA=true
DS_DIRMGRDN="cn=Directory Manager"
DS_DIRMGRPASSWD=dirm4n4ger
 
 
#
# IDPDISCOVERY_ONLY set to true will only configure idpdiscovery service
# COMMON_COOKIE_DOMAIN IDP Discovery service cookie domain
# COOKIE_ENCODE  set to true, common domain cookie will be encoded.
IDPDISCOVERY_ONLY=false
COMMON_COOKIE_DOMAIN=
COOKIE_ENCODE=true
 
############### END OF VARIABLE DEFINITIONS ################################

Run the SAMLv2 installer.

# ./saml2setup install -s saml2silent

When installation is complete, you will see the following message:

Hosted entity descriptor for realm "/" was written to file 
"idpMeta.xml" successfully.
Hosted entity config for realm "/" was written to file
"idpExtended.xml" successfully.
Hosted entity descriptor for realm "/" was written to file
"spMeta.xml successfully.
Hosted entity config for realm "/" was written to file
"spExtended.xml" successfully.
Meta data created !!!

Circle of trus "samplecot" is created successfully.


Loading SAML2 schema...
The new AM server war /opt/SUNWam/amserver.war is ready for deploy!

In this deployment example, complete proceeding steps before deploying the WAR file.

Load the SAMLv2 users schema into the Access Manager users instance.

#cd /opt/SUNWam/saml2/ldif
# ldapmodify -h LoadBalancer-2.example.com -p 489 -D "cn=Directory Manager" 
-w dirm4n4ger -f saml2_sds_schema.ldif
modifying entry CN=schema

Go to the directory where you downloaded and unpacked the SAMLv2 patch installation file.

# cd /temp/saml2patch/122983-02
# ls
LEGAL_LICENSE.TXT
LICENSE.TXT
patchinfo
postbackout
postpatch
prebackout
prepatch
README.122983-01
rel_notes.html
SUNWsaml2

Run the SAMLv2 patch installer.
# cd /temp/saml2patch # patchadd -G 122983-02
When installation is complete, you will see the following message:
Patch packages installed: SUNWsaml2

Go to the directory where the SAMLv2 update script is located.
# cd /opt/SUNWam/saml2/bin

Run the update script.
# ./saml2setup update -s saml2silent
Any updates required because of the newly-installed patch are made in SAMLv2.

Restart Access Manager 2.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com # ./stop;./start
This deployment uses Sun Java System Web Server which does not require you to redeploy the Access Manager WAR file at this point. If you are using any other web container, you must redeploy the Access Manager WAR file before restarting the Access Manager 1 server.

Troubleshooting

8.2 Configuring the Access Manager Load Balancer for the SAMLv2 Protocols

Follow the instructions that come with your load balancer hardware and software for installing and setting up the load balancer. Set up Load Balancer 3 using the following settings:

Table 8–1 Access Manager Load Balancer Settings


Setting	Value
Load Balancing Method	Round Robin
Persistence	Active HTTP cookie with insert value
SSL Termination	Enabled

8.3 Configuring the Access Manager Servers to Use SAMLv2 User Schema

The final task in configuring the Access Manager servers is to configure them to use SAMLv2 user schema.

To Reconfigure the LDAPv3 Plug-In on the Access Manager User Instances

On the Realms page, click the users realm name.

Click the Data Stores tab.

On the Data Stores tab, click the usersLDAP Data Store name.

On the “LDAPv3 Repository Plugin” page, make the following changes:
1. Add a new LDAP User Object Class.
  
  In the Add box for LDAP User Object Class, enter the following and then click Add:
  sunFMSAML2NameIdentifier
2. Add a new LDAP User Attribute.
  
  In the Add box for LDAP User Attributes, enter the following and then click Add:
  sun-fm-saml2-nameid-infokey
3. Add a second new LDAP User Attribute.
  
  In the Add box for LDAP User Attributes, enter the following and then click Add:
  sun-fm-saml2-nameid-info

Click Save.

Chapter 9 Setting Up the Identity Provider Keystores

In this phase of the deployment, you create SAMLv2 metadata that is recognized by and required by the Liberty Identity protocols. Federation Manager provides sample templates that you can modify to suit your environment.

This chapter contains detailed information about the following groups of tasks:

9.1 Configuring the Keystore for Access Manager 1

Use the Java keytool command to create private keys for XML signing and SAML encryption. Once the keys and stored in a keystore, you extract a certificate request from the keystore, and then submit the request to a trusted Certificate Authority (CA). The trusted CA sends you a certificate which will be used for XML signing.

Use the following as your checklist for configuring the keystore for Federation Manager 1:

To Obtain an XML Signing Certificate from a Trusted Certificate Authority

As a root user, log in to the Access Manager 1 host.

Go to the following directory:

/etc/opt/SUNWam/config

Create a keystore with a private key.

A keystore is a database for storing XML signing certificates, your private keys, and your public keys. For detailed information about keystores and about using the keytool utility to create and manage keystores, see http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.

Use the keytool utility that comes with JDK and is installed with Access Manager. Example:

# cd /etc/opt/SUNWam/config
# which keytool
 /usr/jdk/instances/jdk/1.5.0_06/bin/keytool
# keytool -genkey -alias LoadBalancer-3 -keyalg RSA -keysize 1024 
-dname "cn=LoadBalancer-3.example.com,o=example.com" -validity 365 
-keystore amkeystore
Enter keystore password: passwordam
Enter key password for <LoadBalancer-3>
			  (RETURN if same as keystore password): keypasswordam

Note –

The keystore password you specify here must be identical to the keystore password you specify when you install a copy of this certificate onto Access Manager 2. The two Access Managers will be recognized as a single entity.

Verify that the keystore and private key were created properly.

You should be able to see amkeystore in the following directory, and verify that the current date is within the certificate's valid date range.

# cd /etc/opt/SUNWam/config
# ls -lrt
-rw-r--r--		1 root		root		1261 Nov 2 11:03  amkeystore
# keytool -list -keystore amkeystore -alias LoadBalancer-3 -v
# Enter keystore password: passwordam
Alias name: LoadBalancer-3
Creation date: Nov 2, 2006
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Qwner: CN=LoadBalancer-3.example.com, O=example.com
Issuer: CN=LoadBalancer-3.example.com, O=example.com
Serial number: 454a40c1
Valid from: Thu nov 02 11:02:25 PST 2006 until: Fri Nov 02 12:02:25 PDT 2007
Certificate fingerprints:
			MDS:  60:11:C7:01:51:D0:7C:BC:16:26:E7:C0:54:98:6D:9D
			SHA1: 37:E7:15:91:45:C0:EF:49:A1:CC:EF:9E:64:6C:E2:1E:52:90:3D:4E

Submit a request to a trusted certificate authority (CA) for an XML signing certificate.

Create the request.

# cd /etc/opt/SUNWam/config
# keytool -certreq -alias LoadBalancer-3 -file am.sign.cert -keystore amkeystore
Enter keystore password: passwordam
Enter key password for <LoadBalancer-3>: keypasswordam

Verify that the request text was successfully generated.

# vi am.sign.cer
-----BEGIN NEW CERTIFICATE REQUEST-----
mllBdjCB4AlBADA3MR1wEAYDVQQKEwlzaXjvZs5jb20xlTAfBgNVBAMTGGxvYWRiYWkhbmNlci05
LnNpcm9IlmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgykCgYEAozsGuaqGlL1Z5j6n+aXYACUh
KFpb8f451GG5Eg6Vy862hlstl1b8KaAYARHk0lGjzwb26AiLXlWpDyOmf2hXR91po7oo/Vw/K9Qv
qv/+7FDtCBp9DkcnHXR4aKNGknZ58Rn/VbURGqipvXSe2J+5EB46Nnq8jlGMba/2eSjeRfsCAwEA
AaAAMA0GCSqGSlb3DQEBBAUAA4GBAJ3u+f5mC7AVXErSDucNHZn4Li42ULQBEZmTk3K73U9Ar4wx
ex2Ee6lAsPDyb3g4jUmduBSkrSbKyxZhPutVZQTlfHkiLbd6vHWl1K97DedLoWlt9nZAo3xZyBym
6UCH0HYVly/TAL8fhsielElg8lsidlejis(hfkeowhkdlgile27uak9pwnbmqkdigleIDUekdo30
-----END OF NEW CERTIFICATE REQUEST-----

Follow the instructions provided by your Certificate Authority (CA) for submitting the am.certreq file and sending the text to the CA.

The CA will process your request, and send you a certificate. When you open the certificate file with an editor, the certificate text will look similar to this:

In this deployment example, the certificate text was saved in a text file named fm.certificate.

After you receive the certificate from the trusted CA, import the certificate into the Load Balancer 3 keystore.

The alias name that you specify here will be used later in the deployment when you configure the Federation protocols.

# keytool -import -alias LoadBalancer-3 -keystore amkeystore 
-file am-sign-approved.cert
Enter keystore password: passwordam
Enter key password for <LoadBalancer-3>: keypasswordam

Top-level certificate in reply:

Owner: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems Inc., L=Santa Clara, ST=California, C=US
Issuer: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems, Inc., L=Santa Clara, ST=California, C=US
Serial number:320
Valid from Mon Aug 16 00:00:00 PDT 2004 until: Mon Aug 16 00:00:00 PDT 2032
Certificate fingerprints:
			MDS:	CD:07:DF:A6:CA:B9:AB:94:FF:CF:17:35:AB:C2:C2:51
			SHA1:9A:B5:F7:54:DE:8A:BC:E9:F6:1D:F1:5B:71:46:72:9E:F0:4E:B8:7A

...is not trusted.  Install reply anyway? [no]:yes

Verify that the certificate is properly installed.

When you run this command, note that the Entry Type must be keyEntry as in this example. The keyEntry type contains both private key and the public certificate chain. You will need both of these. The trustedcertEntry type contains only the public key and no private key.

# keytool -keystore amkeystore -alias LoadBalancer-3 -rfc
Enter keystore password: passwordam
Alias name: LoadBalancer-3
Creation date: Nov 2, 2006
Entry type: keyEntry
Certificate chain length: 2

Certificate text similar to the following is displayed:

Certificate[1]:
-----BEGIN CERTIFICATE-----
MIICYDCCAgqgAwIBAgICBoowDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNjExMDIxOTExMzRaFw0xMDA3MjkxOTExMzRaMDcxEjAQBgNVBAoTCXNp
cm9lLmNvbTEhMB8GA1UEAxMYbG9hZGJhbGFuY2VyLTkuc2lyb2UuY29tMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCjOwa5qoaUuVnknqf5pdgAJSEoWlvx/jnUYbkSDpXLzraEiy2UhvwpoBgB
EeTSUaPPBvboCItchakPI6Z/aFdH3Wmjuij9XD8r1C+q//7sUO0IGn0ORycddHhoo0aSdnnxGf9V
tREaqKm9dJ7Yn7kQHjo2eryMgYxtr/Z5Il5F+wIDAQABo2AwXjARBglghkgBhvhCAQEEBAMCBkAw
DgYDVR0PAQH/BAQDAgTwMB8GA1UdIwQYMBaAFDugITflTCfsWyNLTXDl7cMDUKuuMBgGA1UdEQQR
MA+BDW1hbGxhQHN1bi5jb20wDQYJKoZIhvcNAQEEBQADQQB/6DOB6sRqCZu2OenM9eQR0gube85e
nTTxU4a7x1naFxzYXK1iQ1vMARKMjDb19QEJIEJKZlDK4uS7yMlf1nFS
-----END CERTIFICATE-----
Certificate[2]:
-----BEGIN CERTIFICATE-----
MIICjjCCAjigAwIBAgICAyAwDQYJKoZIhvcNAQEFBQAwgZIxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNDA4MTYwNzAwMDBaFw0zMjA4MTYwNzAwMDBaMIGSMQswCQYDVQQGEwJV
UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExHjAcBgNVBAoTFVN1
biBNaWNyb3N5c3RlbXMgSW5jLjEaMBgGA1UECxMRSWRlbnRpdHkgU2VydmljZXMxHDAaBgNVBAMT
E0NlcnRpZmljYXRlIE1hbmFnZXIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEArPzFAYBufzrX2i7G
/HhBi1RtEjYDHCy15WWytK6ZwbfXUMeyGadHweoZniOBU3VKdHhjIDCjqMMN25/rEM5ozwIDAQAB
o3YwdDARBglghkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUO6AhN+VM
J+xbI0tNcOXtwwNQq64wHwYDVR0jBBgwFoAUO6AhN+VMJ+xbI0tNcOXtwwNQq64wDgYDVR0PAQH/
BAQDAgGGMA0GCSqGSIb3DQEBBQUAA0EAVHUPw/JfaTYTU8rHjR+6Xr6GqNbaT4eZtNXs5wIYljwl
HvLjL/AITbxrinqfFiOB2JAOW+gLxo4j6LV6W9/2Mw==
-----END CERTIFICATE-----

Certificate [1] is the public key. This is the certificate that is presented to remote parties in a federated environment. Certificate [2] represents the certificate that authenticates the trusted authority or certificate issuer.

To Obtain an Encryption Certificate from a Trusted Certificate Authority

The Liberty Identity specification requires all XML files to be signed. You can obtain and use one certificate to use for both signing and encryption. Or as an alternative, you can obtain one certificate to use for signing, and obtain a second certificate to use for encryption. In this deployment, for illustration purposes, one certificate is used for signing, and a second certificate is used for encryption.

As a root user, log in to the Access Manager 1 host.

Go to the following directory:

/etc/opt/SUNWam/config

Create a keystore with a private key.

# keytool -genkey -alias LoadBalancer-3-enc -keyalg RSA -keysize 1024 
-dname "cn=LoadBalancer-3.example.com,o=siroe.com" -validity 365 
-keystore amkeystore
Enter keystore password: passwordam
Enter key password for <LoadBalancer-3-enc>
			  (RETURN if same as keystore password): keypasswordam

Note –

The key password you specify here must be identical to the key password you specify for the signing certificate.

Verify that the keystore and private key were created properly.

You should be able to see amkeystore in the following directory, and verify that the current date is within the certificate's valid date range.

# cd /etc/opt/SUNWam/config
# ls -lrt
-rw-r--r--		1 root		root		1261 Nov 2 11:03  amkeystore
# keytool -list -keystore amkeystore -alias LoadBalancer-3-enc -v
# Enter keystore password: passwordam
Alias name: LoadBalancer-3-enc
Creation date: Nov 7, 2006
Entry type: keyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=loadbalancer-3.example.com
Issuer: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems Inc., L=Santa Clara, ST=California, C=US
Serial number: 68f
Valid from: Tue Nov 07 15:56:17 PST 2006 until: Tue Aug 03 16:56:17 PDT 2010
Certificate fingerprints:
         MD5:  69:9C:CF:F6:0D:7E:F4:A7:A8:C3:DC:CD:2F:EC:1A:F4
         SHA1: 29:2F:71:98:6B:AD:4C:27:F2:53:08:94:E0:4B:AF:62:96:1F:B0:F0
Certificate[2]:
Owner: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems Inc., L=Santa Clara, ST=California, C=US
Issuer: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems Inc., L=Santa Clara, ST=California, C=US
Serial number: 320
Valid from: Mon Aug 16 00:00:00 PDT 2004 until: Mon Aug 16 00:00:00 PDT 2032
Certificate fingerprints:
         MD5:  CD:07:DF:A6:CA:B9:AB:94:FF:CF:17:35:AB:C2:C2:51
         SHA1: 9A:B5:F7:54:DE:8A:BC:E9:F6:1D:F1:5B:71:46:72:9E:F0:4E:B8:7A

Submit a request for an encryption certificate.

Create the request.

# cd /etc/opt/SUNWam/config
# keytool -certreq -alias LoadBalancer-3-enc 
-file am-enc.csr -keystore amkeystore
Enter keystore password: passwordam
Enter key password for <LoadBalancer-3-enc>: keypasswordam

Verify that the request text was successfully generated.

# vi am-enc.csr
-----BEGIN NEW CERTIFICATE REQUEST-----
mllBdjCB4AlBADA3MR1wEAYDVQQKEwlzaXjvZs5jb20xlTAfBgNVBAMTGGxvYWRiYWkhbmNlci05
LnNpcm9IlmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgykCgYEAozsGuaqGlL1Z5j6n+aXYACUh
KFpb8f451GG5Eg6Vy862hlstl1b8KaAYARHk0lGjzwb26AiLXlWpDyOmf2hXR91po7oo/Vw/K9Qv
qv/+7FDtCBp9DkcnHXR4aKNGknZ58Rn/VbURGqipvXSe2J+5EB46Nnq8jlGMba/2eSjeRfsCAwEA
AaAAMA0GCSqGSlb3DQEBBAUAA4GBAJ3u+f5mC7AVXErSDucNHZn4Li42ULQBEZmTk3K73U9Ar4wx
ex2Ee6lAsPDyb3g4jUmduBSkrSbKyxZhPutVZQTlfHkiLbd6vHWl1K97DedLoWlt9nZAo3xZyBym
6UCH0HYVly/TAL8fhsielElg8lsidlejis(hfkeowhkdlgile27uak9pwnbmqkdigleIDUekdo30
-----END OF NEW CERTIFICATE REQUEST-----

Follow the instructions provided by your Certificate Authority (CA) for submitting the cert-enc.csr file and sending the text to the CA.

The CA will process your request, and send you a certificate. When you open the certificate file with an editor, the certificate text will look similar to this:

In this deployment example, the certificate text was saved in a text file named am-enc-cert.

Import the certificate into the Load Balancer 3 keystore.

# keytool -import -alias LoadBalancer-3-enc -keystore amkeystore 
-file am-enc-approved.cert
Enter keystore password: passwordam
Enter key password for <LoadBalancer-3-enc>: keypasswordam

Top-level certificate in reply:

Owner: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems Inc., L=Santa Clara, ST=California, C=US
Issuer: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems, Inc., L=Santa Clara, ST=California, C=US
Serial number:320
Valid from Mon Aug 16 00:00:00 PDT 2004 until: Mon Aug 16 00:00:00 PDT 2032
Certificate fingerprints:
			MDS:	CD:07:DF:A6:CA:B9:AB:94:FF:CF:17:35:AB:C2:C2:51
			SHA1:9A:B5:F7:54:DE:8A:BC:E9:F6:1D:F1:5B:71:46:72:9E:F0:4E:B8:7A

...is not trusted.  Install reply anyway? [no]:yes

Verify that the certificate is properly installed.

# keytool -list -keystore amkeystore -alias LoadBalancer-3-enc -rfc
Enter keystore password: passwordam
Alias name: LoadBalancer-3-enc
Creation date: Nov 2, 2006
Entry type: keyEntry
Certificate chain length: 2

Certificate text similar to the following is displayed:

9.2 Configuring Access Manager 1 to Recognize the New Keystores and Key Files

The XML signature provider, the XML encryption provider, and the Access Manager servers use the keystore configuration in the AMConfig.properties file for signing purposes. By default, Access Manager supports multiple XML signature algorithms. In this deployment example, you explicitly specify the RSA signature algorithm by setting the appropriate property in the AMConfig.properties file.

Use the following as your checklist for configuring Access Manager 1:

To Create the Access Manager 1 Keystore Passwords

As a root user, log into the Access Manager host.

Create a .storepass file.

# cd /etc/opt/SUNWam/config
# /opt/SUNWam/bin/ampassword -e passwordam > .storepass

Create a .keypass file.

# pwd /etc/opt/SUNWam/config
# /opt/SUNWam/bin/ampassword -e keypasswordam > .keypass

To Modify the `AMConfig.properties` File

Go to the following directory:
/etc/opt/SUNWam/config
Make a backup of the AMConfig.properties file before you make changes.

In AMConfig.properties, set the following properties as in this example:

com.sun.identity.saml.xmlsig.keystore=/etc/opt/SUNWam/config/amkeystore
com.sun.identity.saml.xmlsig.storepass=/etc/opt/SUNWam/config/.storepass
com.sun.identity.saml.xmlsig.keypass=/etc/opt/SUNWam/config/.keypass
com.sun.identity.saml.xmlsig.certalias=LoadBalancer-3
...
com.sun.identity.jss.donotInstallAtHighestPriorty=true

Uncomment the following property, and set the value as in this example:

com.sun.identity.saml.xmlsig.xmlSigAlgorithm=
http://www.w3.org/2000/09/xmldsig#rsa-sha1

Save the file.

To Modify the `amsaml.properties` File

Go to the following directory:

/opt/SUNWam/locale

Open the amsaml.properties file and search for the following property:
xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#dsa-sha1

Change the method from dsa-sha1 to rsa-sha1.

xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#dsa-sha1

Restart the Access Manager 1 server.

# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com
# ./stop;./start

9.3 Configuring the Keystore for Access Manager 2

The XML signing certificates must be identical on both Access Manager instances. This ensures that when the SAMLv2 metadata is published, the metadata represents both Access Manager instances as a single entity. In this procedure you copy the XML signing certificate from Access Manager 1 and install the certificate on Access Manager 2.

To Install the Access Manager 1 XML Signing Certificate on Access Manager 2

As a root user, log in to the Access Manager 2 host.

Go to the following directory:

/etc/opt/SUNWam/config

Copy into this directory the keystore files that were created for Access Manager 1.

Verify that the certificate is properly installed.

# keytool -list -keystore amkeystore -alias LoadBalancer-3 -rfc
Enter keystore password: password
Alias name: LoadBalancer-3
Creation date: Nov 2, 2006
Entry type: keyEntry
Certificate chain length: 2

Certificate text similar to the following is displayed:

Certificate[1]:
-----BEGIN CERTIFICATE-----
MIICYDCCAgqgAwIBAgICBoowDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNjExMDIxOTExMzRaFw0xMDA3MjkxOTExMzRaMDcxEjAQBgNVBAoTCXNp
cm9lLmNvbTEhMB8GA1UEAxMYbG9hZGJhbGFuY2VyLTkuc2lyb2UuY29tMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCjOwa5qoaUuVnknqf5pdgAJSEoWlvx/jnUYbkSDpXLzraEiy2UhvwpoBgB
EeTSUaPPBvboCItchakPI6Z/aFdH3Wmjuij9XD8r1C+q//7sUO0IGn0ORycddHhoo0aSdnnxGf9V
tREaqKm9dJ7Yn7kQHjo2eryMgYxtr/Z5Il5F+wIDAQABo2AwXjARBglghkgBhvhCAQEEBAMCBkAw
DgYDVR0PAQH/BAQDAgTwMB8GA1UdIwQYMBaAFDugITflTCfsWyNLTXDl7cMDUKuuMBgGA1UdEQQR
MA+BDW1hbGxhQHN1bi5jb20wDQYJKoZIhvcNAQEEBQADQQB/6DOB6sRqCZu2OenM9eQR0gube85e
nTTxU4a7x1naFxzYXK1iQ1vMARKMjDb19QEJIEJKZlDK4uS7yMlf1nFS
-----END CERTIFICATE-----
Certificate[2]:
-----BEGIN CERTIFICATE-----
MIICjjCCAjigAwIBAgICAyAwDQYJKoZIhvcNAQEFBQAwgZIxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNDA4MTYwNzAwMDBaFw0zMjA4MTYwNzAwMDBaMIGSMQswCQYDVQQGEwJV
UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExHjAcBgNVBAoTFVN1
biBNaWNyb3N5c3RlbXMgSW5jLjEaMBgGA1UECxMRSWRlbnRpdHkgU2VydmljZXMxHDAaBgNVBAMT
E0NlcnRpZmljYXRlIE1hbmFnZXIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEArPzFAYBufzrX2i7G
/HhBi1RtEjYDHCy15WWytK6ZwbfXUMeyGadHweoZniOBU3VKdHhjIDCjqMMN25/rEM5ozwIDAQAB
o3YwdDARBglghkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUO6AhN+VM
J+xbI0tNcOXtwwNQq64wHwYDVR0jBBgwFoAUO6AhN+VMJ+xbI0tNcOXtwwNQq64wDgYDVR0PAQH/
BAQDAgGGMA0GCSqGSIb3DQEBBQUAA0EAVHUPw/JfaTYTU8rHjR+6Xr6GqNbaT4eZtNXs5wIYljwl
HvLjL/AITbxrinqfFiOB2JAOW+gLxo4j6LV6W9/2Mw==
-----END CERTIFICATE-----

9.4 Configuring Access Manager 2 to Recognize the New Keystores and Key Files

Use the following as your checklist for configuring Access Manager 2:

To Create the Access Manager 2 Keystore Passwords

As a root user, log into the Access Manager 2 host.

Create a .storepass file.

# cd /etc/opt/SUNWam/config
# /opt/SUNWam/bin/ampassword -e passwordam > .storepass

Create a .keypass file.

# pwd /etc/opt/SUNWam/config
# /opt/SUNWam/bin/ampassword -e keypasswordam > .keypass

To Modify the `AMConfig.properties` File

Go to the following directory:
/etc/opt/SUNWam/config
Make a backup of the AMConfig.properties file before you make changes.

In AMConfig.properties, set the following properties as in this example:

com.sun.identity.saml.xmlsig.keystore=/etc/opt/SUNWam/config/amkeystore
com.sun.identity.saml.xmlsig.storepass=/etc/opt/SUNWam/config/.storepass
com.sun.identity.saml.xmlsig.keypass=/etc/opt/SUNWam/config/.keypass
com.sun.identity.saml.xmlsig.certalias=LoadBalancer-3
...
com.sun.identity.jss.donotInstallAtHighestPriorty=true

Uncomment the following property, and set the value as in this example:

com.sun.identity.saml.xmlsig.xmlSigAlgorithm=
http://www.w3.org/2000/09/xmldsig#rsa-sha1

Save the file.

Modify the `amSAML.properties` File

Go to the following directory:

/opt/SUNWam/locale

Open the amsaml.properties file and search for the following property:
xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#dsa-sha1

Change the method from dsa-sha1 to rsa-sha1.

xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#dsa-sha1

Restart the Access Manager 2 server.

# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com
# ./stop;./start

9.5 Loading the Federation Manager Root CA Certificates into the Access Manager Servers

In this procedure you import a root CA certificate from Federation Manager 1 into the JDK trusted CA certificate for Access Manager 1. This step is not necessary if you are using one of the root CA certificates that come with JDK by default. The JDK default root CA certificates come from Verisign, Thwarte, and other major certificate issuers. In this deployment example, root CA certificates were obtained from certificate issuers that JDK does not recognize by default. So in this deployment example, the following procedure is necessary to establish trust among the local SSO provider (Federation Manager) and remote SSO providers (such as Access Manager).

Use the following as your checklist for loading the Federation Manager root CA certificates onto the Access Manager web containers:

To Load the Root CA Certificate into the Access Manager 1 Web Container

As a root user, log into the Access Manager 1 host.

Locate the JAVAHOME directory and JDK keystore directory for the Access Manager 1 web container.
#cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/config # view server.xml
Locate the following JAVA javahome entry. In this deployment example, it looks like this:
<JAVA javahome="/usr/jdk/entsys-j2se"
To find the JDK keystore file, append the following to the javahome path:
/jre/lib/security
For example, in this deployment example, the JDK keystore is in the following directory:
/usr/jdk/entsys-j2se/jre/lib/security
This directory contains the Access Manager JDK trusted CA files.

Obtain a copy of the Federation Manager 1 JDK root CA certificate.

You can obtain a copy from the certificate issuer. Or you can copy the certificate stored on the Federation Manager 1 host.

In this deployment example, the Federation Manager 1 root CA certificate has already been copied to the following directory on Access Manager 1:
/net/slapd/export/share/cacert

Import the Federation Manager root CA certificate into the Access Manager JDK keystore.

The alias rootCA represents the name of the root CA certificate you want to import.

# cd /usr/jdk/entsys-j2se/jre/lib/security
# keytool -import -keystore cacerts -alias rootCA  
-file /net/slapd/export/share/cacert
Enter keystore password: changeit
Owner: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems Inc., L=Santa Clara, ST=California, C=US
Issuer: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems, Inc., L=Santa Clara, ST=California, C=US
Serial number:320
Valid from Mon Aug 16 00:00:00 PDT 2004 until: Mon Aug 16 00:00:00 PDT 2032
Certificate fingerprints:
			MDS:	CD:07:DF:A6:CA:B9:AB:94:FF:CF:17:35:AB:C2:C2:51
			SHA1:9A:B5:F7:54:DE:8A:BC:E9:F6:1D:F1:5B:71:46:72:9E:F0:4E:B8:7A
Trust this certificate? [no]: yes
Certificate was added to keystore.

To verify that the root CA certificate was successfully imported, run the list command:

# cd /usr/jdk/instances/jdk1.5.0/jre/lib/security
# keytool -list -keystore cacerts -alias rootCA -rfc
Enter keystore password:  changeit
Alias name: rootCA
Creation date: Mar 9, 2007
Entry type: trustedCertEntry
 
-----BEGIN CERTIFICATE-----
MIICjjCCAjigAwIBAgICAyAwDQYJKoZIhvcNAQEFBQAwgZIxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNDA4MTYwNzAwMDBaFw0zMjA4MTYwNzAwMDBaMIGSMQswCQYDVQQGEwJV
UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExHjAcBgNVBAoTFVN1
biBNaWNyb3N5c3RlbXMgSW5jLjEaMBgGA1UECxMRSWRlbnRpdHkgU2VydmljZXMxHDAaBgNVBAMT
E0NlcnRpZmljYXRlIE1hbmFnZXIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEArPzFAYBufzrX2i7G
/HhBi1RtEjYDHCy15WWytK6ZwbfXUMeyGadHweoZniOBU3VKdHhjIDCjqMMN25/rEM5ozwIDAQAB
o3YwdDARBglghkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUO6AhN+VM
J+xbI0tNcOXtwwNQq64wHwYDVR0jBBgwFoAUO6AhN+VMJ+xbI0tNcOXtwwNQq64wDgYDVR0PAQH/
BAQDAgGGMA0GCSqGSIb3DQEBBQUAA0EAVHUPw/JfaTYTU8rHjR+6Xr6GqNbaT4eZtNXs5wIYljwl
HvLjL/AITbxrinqfFiOB2JAOW+gLxo4j6LV6W9/2Mw==
-----END CERTIFICATE-----

To Load the Root CA Certificate into the Access Manager 2 Web Container

As a root user, log into the Access Manager 2 host.

Locate the JAVAHOME directory and JDK keystore directory for the Access Manager 2 web container.
#cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/config # view server.xml
Locate the following JAVA javahome entry. In this deployment example, it looks like this:
<JAVA javahome="/usr/jdk/entsys-j2se"
To find the JDK keystore file, append the following to the javahome path:
/jre/lib/security
For example, in this deployment example, the JDK keystore is in the following directory:
/usr/jdk/entsys-j2se/jre/lib/security
This directory contains the Access Manager JDK trusted CA files.

Obtain a copy of the Federation Manager 1 root CA certificate.

You can obtain a copy from the certificate issuer. Or you can copy the certificate stored on the Federation Manager 1 host.

In this deployment example, the Federation Manager 1 root CA certificate has already been copied to the following directory on Access Manager 1:
/net/slapd/export/share/cacert

Import the Federation Manager root CA certificate into the Access Manager JDK keystore.

The alias rootCA represents the name of the root CA certificate you want to import.

# cd /usr/jdk/entsys-j2se/jre/lib/security
# keytool -import -keystore cacerts -alias rootCA  
-file /net/slapd/export/share/cacert
Enter keystore password: changeit
Owner: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems Inc., L=Santa Clara, ST=California, C=US
Issuer: CN=Certificate Manager, OU=Identity Services, 
O=Sun Microsystems, Inc., L=Santa Clara, ST=California, C=US
Serial number:320
Valid from Mon Aug 16 00:00:00 PDT 2004 until: Mon Aug 16 00:00:00 PDT 2032
Certificate fingerprints:
			MDS:	CD:07:DF:A6:CA:B9:AB:94:FF:CF:17:35:AB:C2:C2:51
			SHA1:9A:B5:F7:54:DE:8A:BC:E9:F6:1D:F1:5B:71:46:72:9E:F0:4E:B8:7A
Trust this certificate? [no]: yes
Certificate was added to keystore.

To verify that the root CA certificate was successfully imported, run the list command:

# cd /usr/jdk/instances/jdk1.5.0/jre/lib/security
# keytool -list -keystore cacerts -alias rootCA -rfc
Enter keystore password:  changeit
Alias name: rootCA
Creation date: Mar 9, 2007
Entry type: trustedCertEntry
 
-----BEGIN CERTIFICATE-----
MIICjjCCAjigAwIBAgICAyAwDQYJKoZIhvcNAQEFBQAwgZIxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNDA4MTYwNzAwMDBaFw0zMjA4MTYwNzAwMDBaMIGSMQswCQYDVQQGEwJV
UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExHjAcBgNVBAoTFVN1
biBNaWNyb3N5c3RlbXMgSW5jLjEaMBgGA1UECxMRSWRlbnRpdHkgU2VydmljZXMxHDAaBgNVBAMT
E0NlcnRpZmljYXRlIE1hbmFnZXIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEArPzFAYBufzrX2i7G
/HhBi1RtEjYDHCy15WWytK6ZwbfXUMeyGadHweoZniOBU3VKdHhjIDCjqMMN25/rEM5ozwIDAQAB
o3YwdDARBglghkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUO6AhN+VM
J+xbI0tNcOXtwwNQq64wHwYDVR0jBBgwFoAUO6AhN+VMJ+xbI0tNcOXtwwNQq64wDgYDVR0PAQH/
BAQDAgGGMA0GCSqGSIb3DQEBBQUAA0EAVHUPw/JfaTYTU8rHjR+6Xr6GqNbaT4eZtNXs5wIYljwl
HvLjL/AITbxrinqfFiOB2JAOW+gLxo4j6LV6W9/2Mw==
-----END CERTIFICATE-----

Chapter 10 Configuring SAMLv2 Metadata for the Access Manager Servers

Use the following as your checklist for configuring SAMLv2 metadata for the Access Manager servers:

10.1 Creating a Circle of Trust

When you create metadata for the Identity Provider, the Identity Provider entity is added to a circle of trust. A circle of trust is used to group Service Providers and Identity Providers in a secure, trusted environment. Other remote provider entities can be added to the circle of trust. Whenever the SAMLv2 protocol is initiated, the SAMLv2 plug-in determines which circle of trust the requesting entity belongs to, and what other providers are available to interact with it. All entities within the same circle of trust can participate in the SAMLv2 protocols.

To Create a Circle of Trust

As a root user, log into the Access Manager 1 host.

Run the cotcreate command:

# /opt/SUNWam/saml2/bin/saml2meta cotcreate -u amadmin 
-w 4m4dmin1 -r /users -t saml2_circle_of_trust 
Circle of trust "saml2_circle_of_trust" is created successfully.

10.2 Configuring the SAMLv2 Identity Provider Metadata

Federation Manager provides two metadata templates you can customize to meet your needs. For examples of customized metadata templates, see 7.2.1 Sample Metadata Template Files at the end of this chapter.

To Generate and Customize the Identity Provider Template Files

As a root user, lo into the Access Manager 1 host.

Go to the following directory:
/opt/SUNWam/saml2/bin

Generate the SAMLv2 template files.

# ./saml2meta template -u amadmin -w 4m4dmin1 -e loadbalancer-3.example.com 
-d /users/idp -b LoadBalancer-3 -g LoadBalancer-3-enc 
-m /etc/opt/SUNWam/config/saml2-idp-template.xml  
-x /etc/opt/SUNWam/config/saml2-idp-extented-template.xml
Hosted entity descriptor for realm "/" was written to the file
"/etc/opt/SUNWam/config/saml2-idp-template.html" successfully.
Hosted entity config for realm "/" was written to the file
"/etc/opt/SUNWam/config/saml2-idp-extended-template.html" successfully.

The saml2-idp-extended-template.xmlis similar to the standard saml2-idp-template.xml file. However, the extended file contains data about the SAMLv2 plug-in that is specific to Federation Manager.

Customize the saml2–idp-template.xml file.

When the file is first generated, default values are automatically generated and placed in the file. You must manually change these values to match the actual deployment environment. In this deployment example, a load balancer with SSL termination is being used. So you must modify the file to use the HTTPS protocol and the load balancer service URL.
# vi /etc/opt/SUNWam/config/saml2-idp-template.xml
1. In each location URL and each response location URL, change the protocol http to https.
  
  Search for each occurrence of location and response location to be sure you have changed each URL.
2. Globally change all occurrences of AccessManager-1 to LoadBalancer-3.
3. Globally change all occurrences of 1080 to 9443.
Save the file.

Customize the saml2-sp-extended-template.xml file.

# vi /etc/opt/SUNWam/config/saml2-idp-extended-template.xml

Modify the following attribute-pair values to enable XML signing.

<Attribute name="wantArtifactResponseSigned">
						<Value>true</Value>
<Attribute name="wantLogoutRequestSigned">
 					<Value>true</Value>
<Attribute name="wantLogoutResponseSigned">
 					<Value>true</Value>
<Attribute name="wantMNIRequestSigned">
 					<Value>true</Value>
<Attribute name="wantMNIResponseSigned">
 					<Value>true</Value>
<Attribute name="cotlist">
 					<Value>saml2_circle_of_trust</Value>

Set the following parameter value:
<EntityConfig xmlns="urn:sun:fm:SAML:2.0:entityconfig" xmlns:fm="urn:sun:fm:SAML:2.0:entityconfig" hosted="1"
This indicates that you are using the local hosted configuration. A 0 value indicates that the configuration is provided by a remote host.

Load the metadata.

See 7.3 Loading the Service Provider SAMLv2 Metadata.

10.3 Loading the SAMLv2 Metadata

When you load the SAMLv2 metadata into Directory Server, the Service Provider entity configuration is created. The entity configuration enables the SAMLv2 plug-in to recognize all SAMLv2 protocol URLs. The SAMLv2 metadata is also used for exchanging data with remote parties.

To Load Customized Identity Provider Configuration Files

As a root user, log into the Access Manager 1 host.

Go to the following directory:
/etc/opt/SUNWam/config

Run the saml2meta command:

# ./saml2meta import -u amadmin -w 4m4dmin1 -r /users 
-m /etc/opt/SUNWam/config/saml2-idp-template.xml 
-x /etc/opt/SUNWam/config/saml2-idp-extended-template.xml
File “/etc/opt/SUNWam/config/saml12-idp-template.xml” 
was imported successfully. 
File “/etc/opt/SUNWam/config/saml2-idp-extended-template.xml” 
was imported successfully.

10.4 Sample Identity Provider Metadata Template Files

In the following examples, changes to the file are indicated in bold.

Example 10–1 Modified `saml2-idp-template.xml` File

<EntityDescriptor
    xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="loadbalancer-3.example.com">
    <IDPSSODescriptor
        WantAuthnRequestsSigned="false"
        protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <KeyDescriptor use="signing">
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <X509Data>
                    <X509Certificate>
MIICZDCCAg6gAwIBAgICBr8wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNzAzMDcyMTUwMDVaFw0xMDEyMDEyMTUwMDVaMDsxFDASBgNVBAoTC2V4
YW1wbGUuY29tMSMwIQYDVQQDExpMb2FkQmFsYW5jZXItMy5leGFtcGxlLmNvbTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAlOhN9HddLMpE3kCjkPSOFpCkDxTNuhMhcgBkYmSEF/iJcQsLX/ga
pO+W1SIpwqfsjzR5ZvEdtc/8hGumRHqcX3r6XrU0dESM6MW5AbNNJsBnwIV6xZ5QozB4wL4zREhw
zwwYejDVQ/x+8NRESI3ym17tDLEuAKyQBueubgjfic0CAwEAAaNgMF4wEQYJYIZIAYb4QgEBBAQD
AgZAMA4GA1UdDwEB/wQEAwIE8DAfBgNVHSMEGDAWgBQ7oCE35Uwn7FsjS01w5e3DA1CrrjAYBgNV
HREEETAPgQ1tYWxsYUBzdW4uY29tMA0GCSqGSIb3DQEBBAUAA0EAGhJhep7X2hqWJWQoXFcdU7eQ
        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <X509Data>
EwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEeMBwGA1UEChMVU3VuIE1pY3Jvc3lz
dGVtcyBJbmMuMRowGAYDVQQLExFJZGVudGl0eSBTZXJ2aWNlczEcMBoGA1UEAxMTQ2VydGlmaWNh
dGUgTWFuYWdlcjAeFw0wNzAzMDcyMjAxMTVaFw0xMDEyMDEyMjAxMTVaMDsxFDASBgNVBAoTC2V4
YW1wbGUuY29tMSMwIQYDVQQDExpMb2FkQmFsYW5jZXItMy5leGFtcGxlLmNvbTCBnzANBgkqhkiG
HREEETAPgQ1tYWxsYUBzdW4uY29tMA0GCSqGSIb3DQEBBAUAA0EAEgbmnOz2Rvpj9bludb9lEeVa
OA46zRiyt4BPlbgIaFyG6P7GWSddMi/14EimQjjDbr4ZfvlEdPJmimHExZY3KQ==
            </KeyInfo>
            </EncryptionMethod>
        </KeyDescriptor>
        <ArtifactResolutionService
            index="0"
            isDefault="1"/>
        <SingleLogoutService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
        <SingleLogoutService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
        <ManageNameIDService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
            ResponseLocation="https://LoadBalancer-3.example.com:9443/
               amserver/IDPMniRedirect/metaAlias/idp"/>
        <ManageNameIDService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
            Location="https://LoadBalancer-3.example.com:9443/amserver/
               IDPMniSoap/metaAlias/idp"/>
        <NameIDFormat>
            urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
        </NameIDFormat>
        <NameIDFormat>
            urn:oasis:names:tc:SAML:2.0:nameid-format:transient
        </NameIDFormat>
        <SingleSignOnService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
            Location="https://LoadBalancer-3.example.com:9443/amserver/
                SSORedirect/metaAlias/idp"/>
        <SingleSignOnService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
            Location="https://LoadBalancer-3.example.com:9443/amserver/
                SSOSoap/metaAlias/idp"/>
    </IDPSSODescriptor>
</EntityDescriptor>

Example 10–2 Modified `saml2-idp-metadata-template.xml` File

<EntityConfig xmlns="urn:sun:fm:SAML:2.0:entityconfig"
    xmlns:fm="urn:sun:fm:SAML:2.0:entityconfig"
    hosted="1"
    entityID="loadbalancer-3.example.com">
                                                                                
    <IDPSSOConfig metaAlias="/users/idp">
        <Attribute name="signingCertAlias">
            <Value>LoadBalancer-3</Value>
            <Value>LoadBalancer-3-enc</Value>
        </Attribute>
        </Attribute>
        <Attribute name="basicAuthUser">
        <Attribute name="basicAuthPassword">
            <Value></Value>
            <Value>false</Value>
        </Attribute>
        <Attribute name="autofedAttribute">
            <Value></Value>
        </Attribute>
        <Attribute name="assertionEffectiveTime">
            <Value>600</Value>
        </Attribute>
        <Attribute name="idpAuthncontextMapper">
        </Attribute>
        <Attribute name="idpAuthncontextClassrefMapping">
        </Attribute>
        <Attribute name="idpAccountMapper">
        </Attribute>
        <Attribute name="idpAttributeMapper">
        </Attribute>
        <Attribute name="attributeMap">
            <Value>EmailAddress=mail</Value>
            <Value>Telephone=telephonenumber</Value>
        </Attribute>
       <Attribute name="wantNameIDEncrypted">
           <Value></Value>
       </Attribute>
        <Attribute name="wantArtifactResolveSigned">
            <Value>true</Value>
        </Attribute>
       <Attribute name="wantLogoutRequestSigned">
           <Value>true</Value>
       </Attribute>
       <Attribute name="wantLogoutResponseSigned ">
           <Value>true</Value>
       </Attribute>
       <Attribute name="wantMNIRequestSigned">
           <Value>true</Value>
       </Attribute>
       <Attribute name="wantMNIResponseSigned">
           <Value>true</Value>
       </Attribute>
       <Attribute name="cotlist">
           <Value>saml2_circle_of_trust</Value>
       </Attribute>
    </IDPSSOConfig>
</EntityConfig>

Part III Setting Up the Identity Provider Site

Chapter 8 Installing the SAMLv2 Plug-in on Access Manager Servers

8.1 Installing the SAMLv2 Plug-In on the Access Manager Servers

To Install the SAMLv2 Plug-In and the SAMLv2 Patch on Access Manager 1

Troubleshooting

To Install the SAMLv2 Plug-In and the SAMLv2 Patch on Access Manager 2

Troubleshooting

8.2 Configuring the Access Manager Load Balancer for the SAMLv2 Protocols

8.3 Configuring the Access Manager Servers to Use SAMLv2 User Schema

To Reconfigure the LDAPv3 Plug-In on the Access Manager User Instances

Chapter 9 Setting Up the Identity Provider Keystores

9.1 Configuring the Keystore for Access Manager 1

To Obtain an XML Signing Certificate from a Trusted Certificate Authority

To Obtain an Encryption Certificate from a Trusted Certificate Authority

9.2 Configuring Access Manager 1 to Recognize the New Keystores and Key Files

To Create the Access Manager 1 Keystore Passwords

To Modify the AMConfig.properties File

To Modify the amsaml.properties File

9.3 Configuring the Keystore for Access Manager 2

To Install the Access Manager 1 XML Signing Certificate on Access Manager 2

9.4 Configuring Access Manager 2 to Recognize the New Keystores and Key Files

To Create the Access Manager 2 Keystore Passwords

To Modify the AMConfig.properties File

Modify the amSAML.properties File

9.5 Loading the Federation Manager Root CA Certificates into the Access Manager Servers

To Load the Root CA Certificate into the Access Manager 1 Web Container

To Load the Root CA Certificate into the Access Manager 2 Web Container

Chapter 10 Configuring SAMLv2 Metadata for the Access Manager Servers

10.1 Creating a Circle of Trust

To Create a Circle of Trust

10.2 Configuring the SAMLv2 Identity Provider Metadata

To Generate and Customize the Identity Provider Template Files

10.3 Loading the SAMLv2 Metadata

To Load Customized Identity Provider Configuration Files

10.4 Sample Identity Provider Metadata Template Files

Example 10–1 Modified saml2-idp-template.xml File

Example 10–2 Modified saml2-idp-metadata-template.xml File

To Modify the `AMConfig.properties` File

To Modify the `amsaml.properties` File

To Modify the `AMConfig.properties` File

Modify the `amSAML.properties` File

Example 10–1 Modified `saml2-idp-template.xml` File

Example 10–2 Modified `saml2-idp-metadata-template.xml` File