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:
keytool -genkey -keypass testkeypass -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -keyalg rsa -alias testalias
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.
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):
Figure 3. Create a new SAML credential mapping provider
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.
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.
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.
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.