You can configure communication between WS-Sec Clients and the Oracle WSM Agent that have been embedded with Security Token Service.
The Oracle WSM Agent protects the Web Service endpoints of Security Token Service, and provides support for WSS protocol exchanges. To ensure a client is communicating successfully with the Oracle WSM Agent:
The client might need to be aware of the signing and encryption certificates used by the Oracle WSM Agent (this will require extracting and distributing the signing and encryption certificates used by the OWSM Agent embedded with Security Token Service).
The Oracle WSM Agent needs to be aware, depending on the policies, of the signing certificate used by the client (this requires adding the client's certificate as a trusted certificate for the Oracle WSM Agent).
You need to perform the following tasks to configure the communication with Oracle WSM agents:
The Oracle WSM Agent requires a repository to retrieve the Web Services Security (WSS) policies it needs.
Access Manager supports two types of repositories for Security Token Service:
JAR file with WSS Policies: Used when the WLS Domain is configured for classpath. The required JAR file is located in $ORACLE_IDM_HOME/oam/server/policy/ sts-policies.jar.
Oracle WSM Policy Manager available from the SOA deployment
During Security Token Service installation, the installer detects if the Oracle Web Services Manager Policy Manager is present and deployed in the WebLogic Security domain.
If not deployed in the WebLogic Security domain, the installer configures the WebLogic Security domain for the Web Services Security Policy classpath mode, where the WSM Agent will retrieve the policies from a JAR file.
If present, the installer connects to the Oracle Web Services Manager Policy Manager and uploads the policies that are used to protect Security Token Service endpoints.
See About the Database Store for Policy, Password Management, and Sessions for details about the required database for Access Manager policy data and (optionally) Access Manager session data.
Administrators need to retrieve the keystore password and key entry password from CSF for certain activities.
Otherwise, keystore or key entry cannot be changed. Having access to the keystore is sometimes required to:
Extract the signing/encryption certificate to distribute to clients if necessary
Update or replace the signing/encryption key entry
Add trusted certificates
During SOAP interactions, the WS-Security protocol might require the client to trust the signing/encryption certificate used for WSS operations by the OWSM Agent protecting the Security Token Service endpoint.
In those cases, the Oracle Access Management Administrator should extract the Security Token Service OWSM signing/encryption certificate used for WSS operations and provide it to the WS Client. The Administrator must export the signing and encryption certificate used by Security Token Service for WSS cryptographic operations. The following procedure guides as you do this by:
Replacing $DOMAIN_HOME with the path to the Domain directory
CERT_FILE with the location of the file where the certificate will be saved
If you are prompted to enter a password, simply press the Enter key.
You can add a trusted certificate to the OWSM keystore for WSS cryptographic operations.
To add a trusted certificate:
Perform the command in the following procedure
Replace the $DOMAIN_HOME with the path to the Domain directory
Replace the TRUSTED_CERT_FILE with the location of the file containing the trusted certificate
Replace the TRUSTED_CERT_ALIAS with the alias under which the trusted certificate will be stored
When prompted to enter a password, enter the password of the OWSM keystore that you retrieved earlier.
The Administrator must have the certificate to import.
When the Oracle WSM Agent performs a certificate validation, it uses the keystore configured for Oracle WSM tasks, and will validate the certificate against the trusted certificate entries contained in the keystore.
For those operations, it might be required to add trusted certificate entries (the certificate itself or the issuer's certificate) in the OWSM keystore. When receiving a SOAP requester, the Oracle WSM Agent processes the request for message protection. Part of the steps might include a certificate validation operation if the incoming message:
is of type WSS 1.0, and includes a digital signature created with a private key, without the certificate being present. In this case:
Remedy: The Oracle WSM keystore must contain the signing certificate.
is of type WSS 1.0, and includes a digital signature created with a private key, with the certificate being present.
Remedy: The Oracle WSM keystore must contain either the signing certificate or the issuer's certificate of the signing certificate.
is of type WSS 1.1, and includes a digital signature created with a private key, without the certificate being present.
Remedy: The Oracle WSM keystore must contain the signing certificate.
is of type WSS 1.1, and includes a digital signature created with a private key, with the certificate being present. In this case, the OWSM keystore will need to contain either the signing certificate or the issuer's certificate of the signing certificate
Remedy: The Oracle WSM keystore must contain either the signing certificate or the issuer's certificate of the signing certificate
If Oracle WSM is the client that will interact with Security Token Service using WSS Kerberos policies, then the entire Oracle WSM Kerberos setup section in Administering Web Services applies.
However, if the client is not Oracle WSM, disregard sections on how to configure the client, sections related to authenticating the user referenced in the Kerberos ticket.
Configure the KDC.
Initialize and Start the MIT Kerberos KDC.
Create Principals.
Note:
Skip the following step 5 and step 6 for Non-Oracle Client.Set the Service Principal Name In the Web Service Client.
Set the Service Principal Name In the Web Service Client at Design Time.
Configure the Web Service to Use the Right KDC.
Use the Correct Keytab File in Enterprise Manager.
Extract and Export the Keytab File.
Modify the krb5 Login Module to use the Keytab File.
Authenticate the User Corresponding to the Service Principal.
Create a Ticket Cache for the Web Service Client.
Use Active Directory with Kerberos and Message Protection.
Note:
Skip step 14 for Non-Oracle Client.Set Up the Web Service Client.
Create a User Account.
Create a Keytab File.
Note:
Skip step 17 for Non-Oracle Client.Set the Service Principal Name.
Set Up the Web Service.