Configuring Single Sign-On using SAML in WebLogic Server 9.2
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:
- Open the DOS command window and change the directory to
- 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
keytool -export -keypass testkeypass -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias testalias -file testalias.der
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):
- Log in to the WebLogic Server Administration Console on
- In the administration console, select Security Realms in the Domain Structure window
- Select a security realm. The default realm used is myrealm.
- Select the Providers tab, and then select the Credential Mappings tab.
- If SAMLCredentialMapper doesn't exist, then create a new SAMLCredentialMapper, as shown in Figure 3.
- Select SAMLCredentialMapper, and then select Provider Specific.
- In the Change Center window, select Lock and Edit; this will allow you to edit the SAMLCredentialMapper settings.
- 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.
- Enter the Signing Key Alias (testalias) and the Signing Key Pass Phrase (testkeypass). You used these values when you generated the keystore.
- Set the Default time to Live and Cred Cache Min Viable TTL and other values, as shown in Figure 4.
- Click Save.
- In the Change Center window, click Activate Changes.
Figure 3. Create a new SAML credential mapping provider
Figure 4. SAML credential mapping provider settings
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.
- On the Management tab, click Relying Parties.
- In the Relying Parties table, click New.
- 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.
- Set the relying party values, as listed in Table 3.
Figure 5. Relying party configuration
|Enabled||Select the checkbox(true)|
|Assertion Consumer URL||https://localhost:7004/samlacs/acs|
|Assertion Consumer Parameters||APID= ap_00001|
|Signature Required||Select the checkbox(true)|
|Include Keyinfo||Select the checkbox(true)|
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.