3 Credentials (CSF Keys and Certificates)

OMCe uses the Credential Store Framework (CSF) to manage credentials, allowing you to store, retrieve, update, and delete credentials for web services and other apps.

CSF keys are credentials that use basic authentication (user name and password) to certify the authority of users and system components.

Certificates are electronic documents used to authenticate an individual or organization. There are a few different kinds of certificates:

• Web Service Certificates can be trusted certificates containing only a public key or certificates that contain both public and private key information. Web Service Certificates are stored in the Oracle WSM Keystore.

• Token (Signing) Certificates are standard X509 certificates used to securely sign all tokens issued by a federation server. For third-party tokens, you configure Token Issuer Certificate and Signing Authority Certificate information, along with any intermediate certificates, to establish a chain of trust. For details, see Adding a Token Issuer.

• Secure Sockets Layer (SSL) Certificates are trusted certificates that you use to establish SSL communication with the external service. SSL Certificates are stored in the Trust Keystore.

CSF keys and certificates are configured from the Settings > Credentials dialog. CSF keys, certificates, and their values are specific to the OMCe instance where they are defined.

Managing Keys and Certificates

CSF keys and certificates are managed from the Credentials dialog.

As administrator, you manage the credential keys and certificates used by service developers from To open the Credentials dialog:

1. Click and select Settings > Credentials from the side menu.
2. Click the Keys, Certificates, or Token Issuer tab.
3. Select an alias in the Available Keys or Available Certificates list to view the details of the key or certificate. Only the CSF keys and certificates that are currently in use are listed.
   • For CSF Keys, select Show only referenced keys with null values to see only keys that are referenced by artifacts that have no credential values.
   • For certificates, click Export to save the selected certificate to a file. You can then import the certificate for use in another instance.

Configuring a CSF Key

You can configure a new CSF key from the Keys tab in the Credentials dialog. You can edit the description, user name, or password of an existing key, but the key name can’t be changed after it’s created.

1. Click the Keys tab.
2. Click Add and provide the following values:
   • Unique key name. This name can’t be changed after the key is created.
   • User name and password for the external system that requires this key for access.
3. Save the key.

Configuring a Web Service or Token Certificate

You can configure a new web service or token certificate from the Certificates tab in the Credentials dialog. You can’t edit a certificate after it’s created.

1. Click the Certificates tab.
2. Click Add and provide the following information:
   • Alias — Enter a unique name for the certificate.
   • Content — Copy the certificate definition into the text field. You can get Web Service certificate content from the system administrator of the service, or token certificate content from the remote identity provider.
3. Save the certificate.

Note:

When a certificate is uploaded, it takes a few seconds before the certificate is available. Token certificates can take up to ten minutes.

To delete a certificate, click X by the selected alias in the list of Available Certificates. You can only delete certificates that you created.

Configuring an SSL Certificate

You can configure a new SSL Certificate from the Certificates tab in the Credentials dialog. You can’t edit a certificate after you’ve created it.

1. Click the Certificates tab.
2. Click Add and provide the following information:
   • Alias — Enter a unique name for the certificate.
   • Content — Copy the certificate definition into the text field. You can get Web Service certificate content from the system administrator of the service, or token certificate content from the remote identity provider.
   • Select Trusted SSL Certificate.
3. Save the certificate.

Note:

When a certificate is uploaded, it takes a few seconds before the certificate is available.

To delete a certificate, click X by the selected alias in the list of Available Certificates. You can only delete certificates that you created.

Disabling SSL Hostname Verification

Testing connectors can be difficult when they call an outbound service over SSL. If the SSL certificate has an incorrect or missing hostname, the developer might not be able to create the connector or might just have problems with testing.

You can make it easier to test a connector by turning off hostname verification for outbound SSL connections through the Security_IgnoreHostnameVerification policy.

Caution:

Turning off hostname verification is a security risk. Setting this policy to true should be limited to development. When testing is complete, set the policy back to its default value of false.

This policy is set globally (*.*.Security_IgnoreHostnameVerification) and will affect all connectors. Setting the scope for a specific backend or connector is not supported.

For more information on configuring policies, see Policies.

Note:

Even if SSL hostname verification is disabled, you still need to import the SSL certificate if it's self-signed.

Adding a Token Issuer

To authenticate users with third-party tokens, you need to register the token issuers and associate them with their certificates.

After you’ve added at least one token certificate, use the steps below to add a token issuer from the Credentials dialog:

1. Click the Token Issuers tab.
2. Click New Issuer.
3. Enter the name of the token issuer in the Name field under Issuer Details.
4. Click Add (+) and select at least one name from the Select Certificate Subject Names dialog. All the certificates that have been uploaded are listed.
5. Save the token issuer.
6. If the list on the Token Issuers tab doesn’t include your new issuer, click Save in the tab to update the list.
7. (Optional) Click Rules to configure a rule for a certificate subject name.

Configuring Rules

Rules govern how tokens provided by token issuers are processed. If the token provided by a token issuer doesn’t meet the criteria specified by the rule, the request is rejected.

After you’ve added at least one token certificate and created a token issuer, you can configure a rule for the certificate subject name from the Token Issuer tab in the Credentials dialog.

1. On the Token Issuers tab, select a certificate subject name from the list.
2. Click Rules. As you add rules, the current number of rules is indicated on the Rules button.
3. Select Enable Virtual User if you’re configuring rules for users that aren’t registered.
   With virtual users enabled, a token identifies a user with a record in IDCS, but roles are associated with the user based on the default content in the token, instead of on information in that account.
4. Under Add a New Rule, select the rule type.
5. Enter the required values for the rule type.
6. Click Add.

If you need to change a rule, just select it, make the updates and click Done. To delete a rule, select the rule and click X.

Rule Types

Filter Rule

The Filter rule consists of a token attribute and at least one value that must match the value associated with the token. The name-id attribute represents the username identified in the token, while the user.tenant.name attribute represents the tenant name associated with the token.

Use a comma-separated list to enter multiple attribute values for either attribute. If none of the values match, the token is deemed invalid. A value can contain a wildcard (*) character.

For example:

• name-id=jack, jill, ann

• user.tenant.name=testing, development

You can configure only one Filter rule per token attribute (that is, you configure one Filter rule with the name-id attribute and one Filter rule with the user.tenant.name attribute).

User Mapping Rule

The User Mapping rule defines how tokens are mapped to users, either by user name or email address. This rule is applicable only to JWT tokens, only if virtual users are disabled.

The rule consists of a token attribute, name-id, that represents the username identified in the token, and a user attribute name value of either uid or mail:

• uid is the user’s username in the associated IDCS account (default behavior)

• mail is the user’s email address in the IDCS account

You can configure only one User Mapping rule per issuer certificate name. If you don’t configure a User Mapping rule, name matching is used (the default behavior).

Note:

For SAML tokens the User Mapping rule type is ignored and the default behavior is to map the username in the token to the username in the associated record.

Default Role Rule

The Default Role rule defines a list of roles to associate with users. This rule is applicable only if virtual users are enabled.

The rule consists of a list of role names that are assigned to all users presenting tokens verified using the corresponding token certificate. Use a comma-separated list to enter multiple attribute values.

For example:role=technician, manager, tester

You can configure only one Default Role rule per issuer certificate name. If you don’t configure a Default Role rule, no roles are assigned to the requesting user unless you’ve configured a Role Attribute rule.

Role Attribute Rule

Use the Role Attribute rule to determine which roles to assign by examining the attributes in the token. If a Role Attribute role is defined, the token is searched for attributes with names that match any of the values defined in the rule. If matches are detected, the values of those token attributes are interpreted as roles and assigned to the virtual user. This rule is applicable only if virtual users are enabled.

The rule consists of a comma-separated list of token attribute names used to derive the roles that are assigned to users.

For example: employeelevel, QAgroup

You can configure only one Role Attribute rule per issuer certificate name, but you can use this rule in combination with the Role Mapping rule. If you don’t configure a Role Attribute rule, no roles are assigned to the requesting user unless you’ve configured a Default Role rule.

Note:

If you configure both the Default Role rule and the Role Attribute rule and the role attribute you defined is present in the token, the Default Role rule is ignored. However, if the defined role attribute isn’t present, the roles specified in the Default Roles rule are applied to the virtual user. Role Mapping rules can also define which roles to use when no matches are found.

Role Mapping Rule

The Role Mapping rule associates roles with role attributes in the token identified by the Role Attribute rule. This rule is applicable only if virtual users are enabled.

The rule consists of an external role name, which is the value that should be found in one or more token attributes, and a list of roles to which the external role names are mapped. Use a comma-separated list to enter multiple attribute values.

For example: employee=technician, manager, tester

This example maps the external role name, employee, to the existing roles, technician, manager, tester.

Note:

Role Mapping rules only work in conjunction with Role Attribute rules. If no Role Attribute rule is defined, Role Mapping rules are ignored. If the names of the token attributes configured in the Role Attributes rule don’t match the external role names configured in the Role Mapping rule, the token attributes are treated as role names and are assigned to the requesting user. If the role names defined in the rule don’t correspond to any existing roles, the value is ignored.

You can configure as many Role Mapping rules per issuer certificate as you need, but only one rule can be configured for each external role name. To map one external role to multiple roles, use a single rule and include all the roles in a comma-separated list, as shown in the example above.