Create a separate keystore for each Service Profile that needs its own signing certificate. This section covers the following topics:
The default Service Profile (OAuthServiceProfile) created in the DefaultDomain uses the Java Keystore (JKS) included with Oracle Access Management.
The role of the Service Profile is described in Service Profiles - Identity Federation and OAuth Services The OAuthServiceProfile consists of the following files:
Table 53-6 Default OAuth JKS Keystore File and Settings File
File | Path |
---|---|
JKS keystore file |
|
Keystore settings file |
|
Note:
Oracle Web Services Manager also uses the default-keystore.jks
service. For details see About the Oracle Web Services Manager Keystore (default-keystore.jks).
You can use the following Java keytool
command to list all of the private key and certificate information in the default keystore (default-keystore.jks
).
keytool -list -keystore default-keystore.jks
Note:
When a new key is added to the OAM keystore, the OAM server needs to be restarted since keystore changes are not automatically refreshed.
You can find the keystore credential with Oracle Enterprise Manager Fusion Middleware Control Console.
To find the keystore credential:
You can create a non-default keystore for a Service Profile.
The steps in this section describe about:
Note:
Any changes made during this procedure require a restart of the OAM server.
You can create a new Java Keystore (JKS) using the keytool
utility that is distributed with the Java JDK.
To create a new JKS:
You can use the keytool
utility to import the certificates into the keystore.
To import the cerftificates:
You can configure the keystore service and update the credential store so that OAM can read the keystore and keys correctly.
In the jps-config.xml
keystore settings file, add the following new keystore service instance in the <serviceInstances>
element.
You can create the necessary Credential Store Framework (CSF) entries using the WLST commands.
Following are the WLST commands. Restart the server when you are done.
createCred(map="oracle.wsm.security", key="
sign_csf_key
", user="
alias_name
", password=
keystore_password
, desc="
Description of the signing key credential
")
createCred(map="oracle.wsm.security", key="
enc_csf_key
", user="
alias_name
", password=
keystore_password
, desc="Description of the encryption key credential")
createCred(map="oracle.wsm.security", key="
keystore_csf_key
", user="
oauth
", password=
keystore_password
, desc="
Description of the keystore credential
")
Where:
sign_csf_key
= the password for the signing key
alias_name
= the alias name for the key
keystore_password
= the keystore password
enc_csf_key
= the password for the encryption key
keystore_csf_key
= the password for the keystore
Creating Credential Store Entries
createCred(map="oracle.wsm.security", key="oauth-sign-csf-key", user="ms-oauth-key", password=passwordxyz, desc="Signing key credential") createCred(map="oracle.wsm.security", key="oauth-enc-csf-key", user="ms-oauth-key", password=passwordxyz, desc="Encryption key credential") createCred(map="oracle.wsm.security", key="keystore_csf_key", user="oauth", password=passwordxyz, desc="Keystore credential")
You can apply the updated configuration to the Service Profile.
See Creating a Service Profile if you have not yet created an OAuth Service Profile for the third-party service.
You can configure OAuth Services to support specific JSON Web Token (JWT) issuers.
All Trusted Issuers must be defined so the OAM Server can validate the token, the thumbprint (x5t) and the key identifier based on this configuration. If there is a trusted entry already available with the same claim, header values and alias name, that entry will be used.
Figure 53-4 is a screenshot of the OAuth Services Service Profile Configuration Page where Trusted Issuers are defined under the Configuration Settings heading. Three Trusted Issuers are configured in it and the following is true of these configurations.
If a request comes with an assertion in which the Trusted Issuer is "www.example1.com", the kid header is "mykey" and there is no x5t header, the runtime uses the certificate with the "trustpartner1" alias name.
If a request comes with an assertion in which the Trusted Issuer is "www.example2.com", the value of the x5t header is "s7RzuzdlJrDyvMS9ntyvMS9ntZt" and there is no kid header, the runtime uses the certificate with the "trustpartner2" alias name.
If a request comes with an assertion in which the Trusted Issuer is "www.example.corp.com", the value of the kid header is "corpkey" and the value of the x5t header is "cYJ4pHYJrDYvMS9ntZts7Rzuzdl", the runtime uses the certificate with the "trustpartner3" alias name.
Figure 53-4 OAuth Services Service Profile Configuration Page