Configuring Single Sign-On using SAML in WebLogic Server 9.2
Pages: 1, 2, 3, 4, 5

Step 4: Generate and register SSL certificates

To secure communication between the SAML source and destination sites, communication between the source site and destination site should be encrypted. Additionally, certificates should be used to verify the identity of the other party during SAML interaction. In this step I'll create and register certificates that will be used in the communication between the source site and the destination site.

Generate a key using the keytool utility (part of your JDK). By default, a keystore called DemoIdentity.jks will already be configured for domainA and domainB.

Now I'll show how to generate a private key and certificate for test purposes:

1. Open the DOS command window and change the directory to WEBLOGIC_HOME/server/lib directory.
2. Run the keytool command to generate the key, as shown below.

keytool -genkey -keypass testkeypass -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -keyalg rsa -alias testalias

Figure 2. Generate test SSL certificate screen shot

Now run the keytool command with -export option, as shown in Figure 2, to generate a key file called testalias.der:

keytool -export -keypass testkeypass -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias testalias -file testalias.der

SAML Configuration

I'll begin with the SAML source site configuration.

Step 5: Configure domainA, acting as a SAML source site

In this step I will create and configure a SAML Credential Mapper V2 instance. The SAML Credential Mapper acts as a producer of SAML security assertions, allowing domainA to act as a source site for using SAML for SSO.
A SAML security assertion is a package of information that supplies one or more statements made by a SAML authority (meaning an asserting party). The statements made are of the following types; authentication statements, attribute statements, and authorization decision statements.

I'll start by configuring a SAML Credential Mapper V2 instance (note that the SAML Credential Mapper V1 is deprecated as of BEA WebLogic Server 9.2):

1. Log in to the WebLogic Server Administration Console on domainA( http://localhost:7001/console).
2. In the administration console, select Security Realms in the Domain Structure window
3. Select a security realm. The default realm used is myrealm.
4. Select the Providers tab, and then select the Credential Mappings tab.
5. If SAMLCredentialMapper doesn't exist, then create a new SAMLCredentialMapper, as shown in Figure 3.

Figure 3. Create a new SAML credential mapping provider

6. Select SAMLCredentialMapper, and then select Provider Specific.
7. In the Change Center window, select Lock and Edit; this will allow you to edit the SAMLCredentialMapper settings.
8. Edit the issuer URI, http://www.bea.com/demoSAML. This unique URI tells the destination site ( domainB/appB) the origin of the SAML message and allows it to match with the key. Typically, the URL is used to guarantee uniqueness.
9. Enter the Signing Key Alias (testalias) and the Signing Key Pass Phrase (testkeypass). You used these values when you generated the keystore.
10. Set the Default time to Live and Cred Cache Min Viable TTL and other values, as shown in Figure 4.

Figure 4. SAML credential mapping provider settings

11. Click Save.
12. In the Change Center window, click Activate Changes.

At this point the SAML credential mapper provider is configured to allow domainA to act as a source site (source of SAML security assertions) and also it is configured to use the keystore you generated in Step 4.

Step 6: Configure relying party properties

In this step I'll create and configure a relying party. When you configure WebLogic Server to act as a source of SAML security assertions, you need to register the parties that may request SAML assertions that will be accepted. For a SAML relying party, you can specify: the SAML profile used, details about the relying party, and the attributes expected in assertions for the relying party.

The relying party determines whether it trusts the assertions provided to it by the asserting party. SAML defines a number of mechanisms that enable the relying party to trust the assertions provided to it.

1. On the Management tab, click Relying Parties.
2. In the Relying Parties table, click New.
3. In the Profile pull-down menu, select Browser/POST. In the Description field, enter the name demoSAML to identify the relying party, as shown in Figure 5.

Figure 5. Relying party configuration

4. Set the relying party values, as listed in Table 3.

Table 3. Relying Party (rp_00001) Values

Although a relying party may trust the assertions provided to it for user ssouser, the local access policy on the destination site application appB on domainB defines whether the subject ( ssouser) may access local resources.