This chapter includes the following sections:
Viewing the General OWSM Domain Configuration Using Fusion Middleware Control
Configuring Domain-Level Authentication Using Fusion Middleware Control
Domain-Level Message Security Configuration Using Fusion Middleware Control
OWSM Policy Access Configuration Using Fusion Middleware Control
About Managing OWSM Domain Configuration Properties Using WLST
OWSM provides the capability for an administrator to configure and manage the OWSM environment from a central location using the WSM Domain Configuration page in Fusion Middleware Control. From this page you can specify the Policy Manager connection information, cache refresh rates, nonce timeout, clock skew, OWSM keystore configuration, login modules, trusted SAML issuers, and other similar configuration parameters.
WLST commands also provide the ability to configure OWSM from the command line or using scripts. For more information about the WLST commands, see "About Managing OWSM Domain Configuration Properties Using WLST".
OWSM configurations are stored as documents in the OWSM Repository. When you install Fusion Middleware and create a domain that includes OWSM, the following configuration documents are created by default:
Bootstrap configuration document—Contains bootstrap information that is used to connect to the Policy Manager. If you modify the domain configuration (using Fusion Middleware Control or WLST) for a property that is also specified in the bootstrap configuration document, then the value specified in the bootstrap configuration is used only for the initial Policy Manager connection. For any subsequent access, the value in the domain configuration document is used.
The bootstrap configuration document is stored in the domain_home
/config/fmwconfig/wsm-config.xml
file, where domain_home
is the directory in which you installed your domain. By default this directory is Oracle_Home
/user_projects/domains/base_domain
.
Token issuer trust document—Contains the default trusted SAML issuer, www.oracle.com
. This document is read-only. As you add trusted issuers and define DN lists, additional trust documents are created and stored in the repository.
Default configuration document—Contains all of the properties valid for the context with their default values. When you modify the default configuration, a configuration document for the domain is created and saved in the repository.
Note that the configuration performed using the WSM Domain Configuration page or using the custom configuration WLST commands applies at the domain level only, not to the application level.
In most cases, changes made to the OWSM configuration do not require a server restart. In certain situations, however, such as changing the keystore configuration or keystore type, changes to the configuration require a server restart. Additionally, if you modify any cache properties (such as cache.refresh
) and you want the changes to go into effect immediately, you should restart the server.
You manage the configuration of OWSM using the WSM Domain Configuration page. From this page you can view general information about the domain, and configure authentication, message security, and policy access properties. This topic describes the procedure to navigate to the WSM Domain Configuration page.
To navigate to the WSM Domain Configuration page:
The General tab on the WSM Domain Configuration page provides basic information about the domain such as domain name and platform type, and enables you to provide a display name and description for the domain. This section describes the procedure to view this general information.
Version information about the domain is also shown, including the version number of the configuration, timestamp for the last update to the configuration, and the name of the user who last updated the domain.
Note:
Version information is updated only if you use a database-based OWSM Repository.
To view general information about the domain:
The Authentication tab on the WSM Domain Configuration page provides the ability to configure SAML trust, the lifetime to be used for the issued token, and subject properties for JAAS subjects that are created after OWSM authentication. You can also configure SAML, SAML2, Kerberos, X509, and custom login modules.
The configuration details are described in the following sections:
SAML Trusted Issuers and DN Lists Using Fusion Middleware Control
Configuring JWT Trusted Issuers and DN Lists Using Fusion Middleware Control
Configuring Token Attribute Rules for Trusted Issuers Using Fusion Middleware Control
Configuring the Lifetime for the Issued Token Using Fusion Middleware Control
Configuring the SAML and SAML2 Login Modules Using Fusion Middleware Control
Configuring Subject Properties Using Fusion Middleware Control
Configuring the X509 Login Module Using Fusion Middleware Control
The SAML Trust section on the Authentication tab enables you to define SAML trusted issuers and a list of trusted distinguished names (DNs) for SAML signing certificates.
The following topics provide information to help you configure SAML trusted issuers and DN lists:
Adding SAML Issuers and Defining a Trusted DN List Using Fusion Middleware Control
Deleting Trusted Issuers, DNs, or DN Lists Using Fusion Middleware Control
To complete these tasks using WLST, see "Configuring SAML and JWT Trusted Issuers, DN Lists, and Token Attribute Rules Using WLST".
The list of SAML issuers that you define using the Authentication page becomes the default list that is applicable to all web services in this domain. In addition, when you add an issuer using this method, it does not require a restart of the domain.
By default, OWSM checks the incoming issuer name against the list of configured issuers, and checks the SAML signature against the configured certificates in the OWSM keystore. If you defined a trusted DNs list for a trusted issuer, OWSM also verifies that the SAML signature is signed by a certificate whose DN belongs to the trusted DN list.
Configuration of the trusted DNs list is optional; it is available for users that require more fine-grained control to associate each issuer with a list of one or more signing certificates. If you do not define a list of DNs for a trusted issuer, then OWSM allows signing by any certificate, as long as all the intermediate certificates and the CA certificate in the certificate chain for the signing certificate are present in the OWSM keystore. If the signing certificate is self-signed, it must be in the keystore itself.
Important Notes:
Using the Trusted STS and Trusted Clients tables in the SAML Trust section, you define the DNs of the signing certificates, not the certificates themselves.
The CA and intermediate certificates for the signing certificate must be in the OWSM keystore regardless of whether the signing certificate is in the keystore or passed in the message.
For two-way SSL:
The certificate needs to be imported into the trust store for the Java EE container.
The DN of the client SSL certificates are used for validation and must be present in the trusted DNs list.
In all cases, the signing certificates must be trusted by the certificates present in the OWSM keystore.
Use the following procedure to add SAML issuers, define a trusted DN list for SAML signing certificates, or to add a DN to the DN list for an issuer:
You can delete issuers, a DN, or a DN list by performing one of the following actions:
To delete a trusted issuer and the DN list, select the row containing the issuer to be deleted and click Delete.
To delete a DN from the DN list, select the row for the trusted issuer and delete the DN from the list.
To delete a DN list, clear the Issuer DN field for the DN to be deleted. Note that any configured token rules are also deleted.
The JWT Trust section on the Authentication tab enables you to define JWT trusted issuers and a list of trusted distinguished names (DNs) for JWT signing certificates.
The following topics provide information to help you configure JWT trusted issuers and DN lists:
To delete issuers, a DN, or a DN list, "Deleting Trusted Issuers, DNs, or DN Lists Using Fusion Middleware Control".
To complete these tasks using WLST, see "Configuring SAML and JWT Trusted Issuers, DN Lists, and Token Attribute Rules Using WLST".
The list of JWT issuers that you define using the Authentication page becomes the default list that is applicable to all web services in this domain. In addition, when you add an issuer using this method, it does not require a restart of the domain.
By default, OWSM checks the incoming issuer name against the list of configured issuers, and checks the JWT signature against the configured certificates in the OWSM keystore. If you defined a trusted DNs list for a trusted issuer, OWSM also verifies that the JWT signature is signed by a certificate whose DN belongs to the trusted DN list.
Configuration of the trusted DNs list is optional; it is available for users that require more fine-grained control to associate each issuer with a list of one or more signing certificates. If you do not define a list of DNs for a trusted issuer, then OWSM allows signing by any certificate, as long as all the intermediate certificates and the CA certificate in the certificate chain for the signing certificate are present in the OWSM keystore. If the signing certificate is self-signed, it must be in the keystore itself.
There are increasing requirements to control which users and user attributes are accepted and processed for a particular trusted SAML or JWT token issuer. Token attribute rules allow you to define additional security constraints for the trusted STS server and for the trusted SAML client. Token attribute rules can be defined on top of a trusted DN. For each trusted DN configured for an issuer, a token attribute rule can be configured and applied.
Each rule has two parts: a name ID and an attributes part for user attributes that a DN for a trusted issuer can assert. The name ID and each attribute in the attributes part can contain a filter with multiple values or value patterns to provide constraints for the value of the name ID or the attribute that the DN can assert.
To define token attribute rules using Fusion Middleware Control:
You can specify the lifetime to be used for the issued token when the request message is sent to the Security Token Service (STS).
If the STS sends the token with a different expiry, the runtime looks at the actual expiry of the token and only caches the token for that time. For more information, see "Understanding Token Lifetime and Token Caching".
The default for this property is 28800000 milliseconds (8 hours). To modify the default value, do one of the following:
Enter the desired value directly into the Issued Token Lifetime field.
Use the up/down arrows to increase or decrease the default value.
You can configure the SAML and SAML2 login modules from the OWSM Domain Configuration page.
The SAML policies have associated login modules, as determined by the assertions that make up the policy. When you attach a SAML policy to a web service, you can edit the login module and make any needed changes.
You can configure the following SAML login modules from the OWSM Domain Configuration page:
saml.loginmodule—The SAML login module is a Java Authentication and Authorization Service (JAAS) login module that accepts SAML assertions for a login. The SAML login module enables the web services to run using the login context of the principal created from the SAML assertion.
saml2.loginmodule—The SAML2 login module is a JAAS login module that accepts SAML2 assertions for a login. The SAML2 login module enables the web services to run using the login context of the principal created from the SAML2 assertion.
Note:
The configuration performed on this page takes precedence over any configuration performed in the OPSS login module page.
To configure the SAML login modules in OWSM:
For details about setting these properties using WLST, see "Configuring the SAML and SAML2 Login Modules Using WLST".
The Kerberos policies have an associated JAAS login module that authenticates users using Kerberos protocols. The Kerberos login module has optional properties that you can configure in OWSM. The configuration specified in the OWSM configuration takes precedence over any Kerberos login module configuration in OPSS.
To configure the Kerberos login module in OWSM:
For details about setting these and other Kerberos login module properties using WLST, see "Configuring the Kerberos Login Module Using WLST".
The JAAS subject that is created after OWSM authentication is populated with usernames and roles, including the authenticated role, anonymous role, and application roles.
For more information about these roles, see "Understanding Users and Roles" in Securing Applications with Oracle Platform Security Services.
OPSS supports subject properties for these roles that can be configured in OWSM and passed to OPSS with each invocation. The configuration defined in OWSM applies to all subjects created in OWSM only. It does not affect any subjects created using the OPSS login modules.
To configure subject properties in OWSM:
For details about setting these properties using WLST, see "Configuring Subject Properties Using WLST".
The X509 login module has optional properties that you can configure in OWSM. The configuration specified in the OWSM configuration takes precedence over any X509 login module configuration in OPSS.
To configure the X509 login module:
You can create custom login modules in the OWSM configuration system using Fusion Middleware Control.
For details about creating a login module, see the Java Authentication and Authorization Service (JAAS) LoginModule Developer's Guide at http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASLMDevGuide.html
.
To create a custom login module:
The Message Security tab on the WSM Domain Configuration page provides the ability to configure the OWSM keystore, tune security policy enforcement, specify if the public certificate should be published in the WSDL, and configure hostname verification and secure conversation.
The configuration details are described in the following sections:
OWSM provides support for KSS, JKS, HSM, and PKCS11 keystores. After you create the keystores, you need to configure OWSM so that it can access and use the keystore.
Note:
There is one OWSM keystore per domain, and it is shared by all web services and clients running in the domain.
Note that there is one OWSM keystore per domain, and it is shared by all web services and clients running in the domain.
The following sections describe how to configure OWSM for each keystore type:
You can configure OWSM to use the KSS keystore using the Fusion Middleware Control.
To configure OWSM to use the KSS keystore, perform the following steps:
Note:
If you do not use the default keystore name for the KSS keystore (kss://owsm/keystore
), you must grant permission to the wsm-agent-core.jar
in OPSS. For more information about granting permissions, see "Setting the Java Security Policy Permission" in Securing Applications with Oracle Platform Security Services.
You can configure OWSM to use the JKS Keystore using Fusion Middleware Control.
When you configure OWSM to use the JKS keystore, entries are created in the credential store for the credential map oracle.wsm.security
, and any keys that you define. (For details about configuring the credential store, see "Adding Keys and User Credentials to Configure the Credential Store".)
To configure OWSM to use the JKS keystore:
Hardware Security Modules (HSM), such as SafeNet Luna SA, can be integrated with OWSM to provide a secure way to store keys and off-load cryptographic processing. You can use Fusion Middleware Control to configure OWSM to use the HSM keystore.
To configure OWSM to use the HSM keystore:
The Security Settings section of the Message Security tab allows you to tune the configuration of security policy enforcement by adjusting the default message timestamp skews between system clocks, the time-to-live for nonce messages in the policy cache, and the message expiration time.
To configure security policy enforcement:
The properties in the Identity section of the Message Security tab enable you to specify whether to enforce web service policies by publishing the X509 certificate in the WSDL. If there is no need to publish the X509 certificate (for example, with SSL), you can override the default setting to avoid publishing the certificate. In addition, if the X509 is published, you can also specify whether to ignore the hostname verification feature.
For more information about the service identity certificate extension and hostname verification, see "Understanding Service Identity Certificate Extensions".
Note:
Service identity certificate extension does not set the encryption key from which the public key is derived. You must first specify this key as described in "Overview of Configuring Keystores for Message Protection".
To enable or disable service identity certificate extension and hostname verification:
You can use the Message Security tab on the WSM Domain Configuration page to configure secure conversation for the domain.
The following topics provide information to help you configure secure conversation:
OWSM implements the Web Services Trust and Web Services Secure Conversation specifications, which together provide secure communication between web services and their clients. You can use WS-SecureConversation to increase the performance and security of your web services.
For more detailed information about secure conversation, see "Understanding Secure Conversation" in Understanding Oracle Web Services Manager.
WS-SecureConversation is configurable at the domain level, and at the policy level. If you use the predefined WS-SecureConversation policies provided with OWSM, WS-SecureConversation is already enabled. However, many of the predefined assertion templates provide secure conversation functionality, and policies based on these assertion templates can be configured to use secure conversation. For details about configuring secure conversation at the policy level, see "About Configuring Secure Conversation".
The Policy Access tab on the WSM Domain Configuration page provides the ability to configure the Policy Manager connection for auto-discovery, and whether SSL should be used for the connection. You can also manage the policy cache and configure high availability by tuning the retry logic.
The configuration details are described in the following sections:
Understanding Configuring the Policy Manager Connection Using Fusion Middleware Control
About Refreshing Configuration Cache in OWSM Manually by using Fusion Middleware Control
Configuring SSL for the Policy Manager Connection Using Fusion Middleware Control
High Availability Configuration and Cache Management Using Fusion Middleware Control
The Policy Manager section of the Policy Access tab enables you to configure auto-discovery of the Policy Manager, specify an alternate Policy Manager URL and credential store key and credentials to access the Policy Manager, and modify the refresh configuration and inventory delay settings.
The following topics provide information to help you configure a Policy Manager connection:
OWSM uses an auto-discovery feature to locate and connect to an OWSM Policy Manager. By default, the auto-discovery logic will always connect to the Policy Manager in the local domain using non-secure protocol. If the auto-discovery logic cannot connect to a Policy Manager using non-secure protocol because the non-secure port is disabled, it will attempt to connect to a Policy Manager using secure protocol. However, when using auto-discovery, you can specify whether to use SSL to secure the connection. If you do so, the auto-discovery logic will only connect to Policy Managers using secure protocol and will not try to connect to any Policy Managers deployed on non-SSL servers, even if the SSL-enabled server goes down.
Auto-discovery is supported only in WebLogic domains hosting an OWSM Policy Manager instance. For more information about auto-discovery, see "Cross-Component Wiring for Auto-Discovery of Policy Manager".
You may want to disable auto-discovery in the following scenarios:
Your domain is split into two or more networks, especially if a firewall exists between them.
You are running on a non-WebLogic application server that does not support the auto-discovery feature, such as WebSphere Application Server.
You prefer to override the default settings.
To configure the Policy Manager connection:
Navigate to the WSM Domain Configuration page as described in "Navigating to the WSM Domain Configuration Page".
Select the Policy Access tab and make the following changes in the Policy Manager section of the page.
Specify the credential store key to use to obtain a principal (and its credentials) authorized to access an OWSM Policy Manager instance. You should configure this property when:
You want to specify an explicit account to connect with the OWSM Policy Manager rather than the system account, OracleSystemUser
, that is used by OWSM by default.
The Authentication Provider and LDAP directory that is configured does not support system accounts used by Oracle WebLogic, but which OWSM relies on by default. Therefore, a different account in the LDAP directory must be used.
There is no concept of default system accounts in a particular application server, and so the system cannot rely on system accounts.
For more information on modifying the default user, see "About Modifying the Default User".
To specify the credential store CSF key, do one of the following:
If the desired CSF key exists in the credential store, select it from the PM CSF Key menu. If you select a key from the menu, the Credential and Password fields are disabled and the credentials associated with the selected key will be used.
If the CSF key is not listed in the PM CSF Key menu, enter a name for the CSF key in the PM CSF Key field. Note that you may need to clear the PM CSF Key field before entering a new value. In the Credential field, enter the username to be used to access the Policy Manager instance. In the Password and Confirm fields, enter the password for the username provided in the credential field.
If you do not specify a PM CSF key, then the OracleSystemUser
principal (standard for WebLogic Server environments) is used.
Specify whether the auto-discovery feature of the Policy Manager should be used and, if so, whether SSL is required. If Auto Discover is enabled, the checkbox for specifying whether SSL should be used is active.
By default, auto-discovery is enabled and SSL is disabled. In this case, the auto-discovery logic always attempts to connect to the Policy Manager using non-secure protocol. If it is unable to do so because the non-secure port is disabled, it will attempt to connect to a Policy Manager using secure protocol.
To use auto-discovery with SSL, verify that Auto Discover is selected, then select Use SSL Only. If SSL is enabled, then the auto-discovery logic will only connect to Policy Managers using secure protocol and will not try to connect to any Policy Managers deployed on non-SSL servers, even if the SSL-enabled server goes down.
Auto-discovery is supported only in WebLogic domains hosting an OWSM Policy Manager instance.
To disable the auto-discovery feature, clear the Auto Discover checkbox. If disabled, the Edit icon is enabled and you can manually enter a URL to access a Policy Manager instance as described in the next step.
If auto-discovery is disabled, specify a URL that specifies the location of the Policy Manager. To do so:
Clear the Auto Discover checkbox, if you have not already done so.
Click Edit in the PM URL field.
In the Edit PM URLs window, click the + sign.
Enter the URL for the Policy Manager in the blank field.
The following protocols are valid:
file
://
location_of_mds_home
— Repository is accessed directly as an MDS instance (supported only in Java SE).
classpath
://
JAR_location
— JAR file containing the predefined policies and assertion templates is accessed using the classpath location.
Note:
Because classpath mode is a read-only Policy Manager mode, only design time policy attachments will be in effect. No post-deployment policy attachments or global policy sets will be in effect in this mode.
If you do not provide a value in the URL field, OWSM uses auto-discovery in the same domain using non-secure protocol.
Adjust the Refresh Rate and the Inventory Record Delay if required:
The Refresh Rate specifies the number of milliseconds to wait between configuration refreshes. The default is 600,000 milliseconds (10 minutes).
The Inventory Record Delay specifies the number of milliseconds to wait before sending inventory data. The default is 60,000 milliseconds (1 minute).
Enter a new value in the field or click the up/down arrows to increase or decrease the default value.
Click Apply to apply the property updates.
OWSM has background threads to refresh configuration and documents cache automatically at regular time intervals. This interval is specified in the following properties: refresh.repeat
and cache.refresh.repeat
. You can disable this automatic refresh by setting the value of configuration property auto.refresh
to disabled. Then, you can manually refresh the configuration and documents cache when required.
The properties in the SSL Setup section of the Policy Access tab enable you to configure the type of SSL, if any, to be used for the communication between the OWSM runtime and the Policy Manager.
To configure SSL:
The properties in the Cache Management section of the Policy Access tab enable you to manage the policy cache and configure high availability by tuning the retry logic.
The following topics provide information to help you configure high availability and manage the policy cache:
The configuration management system will periodically reconnect to the Policy Manager (for example, to handle situations when the connection information changes). If the Policy Manager is down when the runtime attempts to reconnect, then it will use the value of the connect.retry.delay
property to determine when it tries again. You can set this property as described in "Configuring the Policy Manager Connection Using WLST".
If the initial connection is made, but the OWSM Repository is not operating properly, then services will start in a "non-operational" state. You can adjust the values of the Failure Retry Count and the Failure Retry Delay properties to determine how may times the Agent will attempt to communicate with the Policy Manager, which in turn accesses the repository, and the time interval between retries. When the repository becomes available, then the services will become operational.
The Initial Cache Refresh and Cache Refresh Time properties can be adjusted to affect how often the Agent attempts to contact the Policy Manager to refresh documents that it has already cached. The Missing Documents Retry Delay property indicates how often the Agent will attempt to connect to the Policy Manager to retrieve a document that it could not retrieve. If a document or group of related documents (such as policy sets) cannot be retrieved because communication with the Policy Manager fails (for example, because it went down), then the Missing Documents Retry Delay property will still affect how often it attempts to communicate with the Policy Manager until it is fixed.
You can use WLST to view and set domain-level configuration properties for OWSM, including authentication, message security, and policy access. You can set most of these configuration properties using the setWSMConfiguration
command.
The following sections provide details:
Additional commands are provided to configure trusted issuers and the message protection keystore. Procedures for using those commands are provided in the following sections:
For reference information about these WLST commands, see "Web Services Custom WLST Commands" in WLST Command Reference for Infrastructure Components.
You can display all of the configuration properties, with their values and groups, as specified in the current configuration document in the repository. If a property is not defined in the configuration document, then the default value defined for the product is displayed.
To view the OWSM domain configuration:
Note that the output displayed above shows the source of the configuration property settings as default
, indicating the setting is from the default configuration document for the product. If you have modified a setting, it is saved in a configuration document for your domain, and will be reflected in the SOURCE
field. For example:
NAME: "remove.anonymous.role" CATEGORY: "SubjectProperties" SOURCE: "/WLS/base_domain" Value: true
You can set the domain-level configuration properties using the setWSMConfiguration
command.
You do not need to use the setWSMConfiguration
command in the context of a session.
To modify the configuration properties for the OWSM domain using the setWSMConfiguration
command:
You can use WLST to set domain level authentication properties for OWSM, including the ability to configure SAML trust, JWT trust, the lifetime to be used for the issued token, and subject properties for JAAS subjects that are created after OWSM authentication. You can also configure SAML, SAML2, Kerberos, X509, and custom login modules.
The configuration details are described in the following sections:
SAML and JWT trusted issuers and DN lists are stored in trust configuration documents in the OWSM repository. To configure trusted issuers and DN lists, you must create a new document or edit an existing document in the repository.
When using WLST to create, modify, and delete token issuer trust documents, you must execute the commands in the context of a session. Each session applies to a single trust document only.
For more information about trusted issuers, DN lists, and token attribute rules, see the following topics:
"SAML Trusted Issuers and DN Lists Using Fusion Middleware Control".
"Configuring Token Attribute Rules for Trusted Issuers Using Fusion Middleware Control"
"Configuring JWT Trusted Issuers and DN Lists Using Fusion Middleware Control"
To configure SAML and JWT trusted issuers, DN lists, and token attribute rules using WLST:
Alternatively, you can choose to cancel any changes by using the abortWSMSession
command, which discards any changes that were made to the repository during the session.
For more information about these commands, see "Token Issuer Trust Configuration Commands" in WLST Command Reference for Infrastructure Components.
Follow the procedure in this section to delete an token issuer trust document from the repository.
To delete an token issuer trust document from the repository:
You can specify the lifetime to be used for the issued token when the request message is sent to the Security Token Service (STS).
If the STS sends the token with a different expiry, the runtime looks at the actual expiry of the token and only caches the token for that time. For more information, see "Understanding Token Lifetime and Token Caching".
To configure the lifetime of the issued token using WLST, use the setWSMConfiguration
command as described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
Use the following settings for this configuration property:
Category: IssuedToken
Name: lifetime
Default: 28800000ms (8 hours)
For example, to change the default value to 25200000 ms (7 hours), use the following command:
wls:/base_domain/serverConfig> setWSMConfiguration (None,'IssuedToken','lifetime',None,['25200000'])
A new property "lifetime" within category "IssuedToken" has been added.
The values "[25200000]" have been added to property "lifetime" within category "IssuedToken".
Configuration properties associated with the context "/WLS/base_domain" has been updated.
This topic describes the OWSM domain-level configuration properties that you can set for the subject properties. To configure subject properties for the domain, use the setWSMConfiguration
command.
This command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
For more information about subject properties, see "Configuring Subject Properties Using Fusion Middleware Control".
Table 14-1 lists the OWSM domain-level configuration properties that you can set for the subject properties.
Table 14-1 Subject Domain Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
SubjectProperties |
add.application.roles |
true |
Flag that specifies if the application roles will be added to the subject created in OWSM. If If set to |
SubjectProperties |
add.authenticated.role |
true |
Flag that specifies if the authenticated role will be added to the Subject created in OWSM. If If set to |
SubjectProperties |
remove.anonymous.role |
false |
Flag that specifies if the anonymous role will be removed from the subject created in OWSM. If If set to |
You can use the setWSMConfiguration
command to configure the SAML and SAML2 login modules by using WLST.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
For more information about these login modules, see "Configuring the SAML and SAML2 Login Modules Using Fusion Middleware Control".
Table 14-2 lists the OWSM domain-level configuration properties that you can set for the SAML and SAML2 login modules.
Table 14-2 SAML and SAML2 Login Module Domain Configuration Properties
Category | Property Name | Default Value | Description |
---|---|---|---|
SAML2LoginModule SAMLLoginModule |
add.assertion.to.subject |
true |
Flag that specifies if the SAML assertion should be added to the authenticated subject as a private credential. If you set this property to false, then the assertion is not added to the authenticated subject. |
SAML2LoginModule SAMLLoginModule |
allow.virtual.user |
false |
Flag that specifies that the SAML subject is allowed to be treated as a virtual user. If set to If this property is set to |
SAML2LoginModule SAMLLoginModule |
dn.mapping.attribute |
CN |
Part of the certificate DN to use for asserting the user against the identity store if the Name Identifier Format is set to X509SubjectName in the SAML client policy. |
SAML2LoginModule SAMLLoginModule |
custom |
N/A |
Use this property to set custom properties to the OPSS login module. |
SAMLLoginModule |
dns.hok |
www.oracle.com |
Defines the list of trusted issuers for the dns.hok token. The DN of the endorser of the SAML token will be checked in the SAML issuer list. Use this property for SAML HOK and SAML bearer. |
SAMLLoginModule |
dns.sv |
www.oracle.com |
Defines the list of trusted issuers for the dns.sv token. The DN of the endorser of the SAML token will be checked in the SAML issuer list. Use this property for SAML sender vouches. |
You can use the setWSMConfiguration
command to configure the Kerberos login module using WLST.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
Table 14-3 lists the OWSM domain-level configuration properties that you can set for the Kerberos login module.
Table 14-3 Kerberos Login Module Domain Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
KerberosLoginModule |
class name |
N/A |
The login module to be used by OWSM. If no value is specified, at runtime one of the following default values will be used for the Kerberos login module Class Name, depending on the platform on which you are running:
|
KerberosLoginModule |
do.not.prompt |
true |
Specifies whether you will be prompted for the password if credentials cannot be obtained from the cache or keytab. When set to |
KerberosLoginModule |
key.tab |
./krb5.keytab |
The file name of the keytab to get the secret key for the principal |
KerberosLoginModule |
principal |
HOST/localhost@EXAMPLE.COM |
The name of the principal to be used. The principal represents a specific entity to which a set of credentials are assigned. It can be a simple username, such as |
KerberosLoginModule |
store.key |
true |
Specifies whether the principal's key is stored in the Subject's private credentials. |
KerberosLoginModule |
use.key.tab |
true |
Specifies whether the module will get the principal's key from the keytab. If the keytab is not set, then the module will locate the keytab from the Kerberos configuration file. If it is not specified in the Kerberos configuration file, then it will look for the file |
KerberosLoginModule |
custom |
N/A |
Use to provide custom properties to the OPSS login module. You can set different groups in this property and these groups will have a single value. |
You can use the setWSMConfiguration
command to configure the X509 login module.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
Table 14-4 lists the domain-level configuration properties that you can set for the X509 login module.
Table 14-4 X509 Login Module Domain-Level Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
X509LoginModule |
dn.mapping.attribute |
CN |
Specifies which part of the certificate DN to use for asserting the user against the identity store. The value that you specify is passed to OPSS with each invocation of the login module. |
x509LoginModule |
custom |
N/A |
Use to provide custom properties to the OPSS login module. You can set different groups in this property and these groups will have a single value. |
You can configure other login modules, and create custom login modules in the OWSM configuration system using the setWSMConfiguration
command.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
For details about creating a login module, see the Java Authentication and Authorization Service (JAAS) LoginModule Developer's Guide at http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASLMDevGuide.html
.
Table 14-5 lists the configuration properties for other login modules that are provided by default.
Table 14-5 Other Login Module Domain Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
DigestLoginModule |
custom |
N/A |
Use to provide custom properties to the OPSS login module. You can set different groups in this property and these groups will have a single value. |
UsernameAssertionLoginModule |
custom |
N/A |
Use to provide custom properties to the OPSS login module. You can set different groups in this property and these groups will have a single value. |
UsernameAuthLoginModule |
custom |
N/A |
Use to provide custom properties to the OPSS login module. You can set different groups in this property and these groups will have a single value. |
WSSDigestLoginModule |
custom |
N/A |
Use to provide custom properties to the OPSS login module. You can set different groups in this property and these groups will have a single value. |
You can use WLST to set domain-level message security properties for OWSM, including the ability to configure the OWSM keystore, tune security policy enforcement, specify if the public certificate should be published in the WSDL and the hostname verified, and secure conversation.
The configuration details are provided in the following sections:
OWSM provides support for KSS, JKS, HSM, and PKCS11 keystores. After you create the keystores, you need to configure OWSM so that it can access and use the keystore. You can configure the OWSM keystore using the configureWSMKeystore
command.
Note that there is one OWSM keystore per domain, and it is shared by all web services and clients running in the domain.
To configure the OWSM keystore:
You can use the setWSMConfiguration
command to configure security policy enforcement.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
Table 14-6 lists the OWSM domain-level configuration properties that you can set for security policy enforcement.
Table 14-6 Security Policy Enforcement Domain-Level Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
Agent |
allow.all.xpaths |
false |
Specifies whether OWSM will accept all types of XPath transformations. By default, OWSM only accepts the XPath transformation Set this property to |
Agent |
use.unified.fault.code |
true |
Specifies whether OWSM will send InvalidSecurity fault codes for all types of errors. If a web service sends different fault codes for different types of errors (such as FailedAuthentication, InvalidSecurityToken, FailedCheck, and so on) there is a possibility of an XML encryption attack. Note: This applies only to security-related faults that originated from OWSM. It does not apply to business faults coming from web services. To avoid these types of attacks, OWSM will send only InvalidSecurity fault codes for all types of errors when this property is set to Set this property to |
Agent |
client.clock.skew |
0 |
Tolerance of time, in seconds, that is used to calculate the |
Agent |
compliance.check |
true |
This property enables compliance checking for various security related configurations/checks and enforces that the incoming message complies to the security requirement of the receiving party. This setting applies to the request message coming to service and the response message coming to the client. It checks for encryption and signature algorithms, encrypted and signed elements and parts, attachment compliance, timestamp compliance, and so on. Setting this property to |
Agent |
clock.skew |
360000 |
Tolerance of time differences between client and server machines. For example, when timestamps are sent across in a message to a service that follows a different time zone, this property allows for the specified time tolerance. Note: This property must have a value greater than or equal to 1 second. If the value is less than 1 second, then the property does not work as expected. For more information about this property, see the description for the Clock Skew property in "Configuring Security Policy Enforcement Using Fusion Middleware Control". |
Agent |
expire.time |
300000 |
Duration of time before a message expires after its creation. This property is used in cases where a timestamp is sent across in the SOAP header to verify if the timestamp has expired or not. For more information about this property, see the description for the Message Expiration Time property in "Configuring Security Policy Enforcement Using Fusion Middleware Control". |
Agent |
nonce.ttl |
28800000 |
Total time-to-live for nonce in the cache when nonce is sent across in a message. This property caches the nonce and once this duration is over, the nonce is removed from the cache. For more information about this property, see the description for the Nonce Time To Live property in "Configuring Security Policy Enforcement Using Fusion Middleware Control". |
Agent |
signature.cache.enable |
false |
If enabled, OWSM will cache the primary signature of SOAP messages in the signature cache for a stipulated time. If a message comes in this time with the same signature, it will be rejected as a duplicate message. To get this functionality By default this property is disabled. You can enable it in the WSM Domain Configuration page. You can also enable it through WLST. |
You can use the setWSMConfiguration
command to configure identity settings.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
For more information about the service identity certificate extension and hostname verification, see "Understanding Service Identity Certificate Extensions".
Note:
Service identity certificate extension does not set the encryption key from which the public key is derived. You must first specify this key as described in "Overview of Configuring Keystores for Message Protection".
Table 14-7 lists the OWSM domain-level configuration properties that you can set for service identity.
Table 14-7 Identity Domain-Level Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
Identity |
ignore.hostname.verification |
true |
Specifies whether to ignore the hostname verification feature per domain. By default this property is disabled (true). However, hostname verification can be enabled by setting the property to false. |
Identity |
ignore.identity.wsdl |
false |
Specifies whether to enable or disable the consumption of the X509 Certificate from a client-side WSDL, per domain. By default, this property is enabled ( |
You can use the setWSMConfiguration
command to configure domain-level secure conversation.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
For more information about domain-level secure conversation, see "Secure Conversation Configuration for the Domain Using Fusion Middleware Control".
Table 14-8 lists the OWSM domain-level configuration properties that you can set for secure conversation.
Table 14-8 Secure Conversation Domain-Level Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
SecureConversation |
token.lifetime |
1800000 |
The default number of seconds after which the secure conversation session should expire. |
SecureConversation |
token.lifetime.reauth |
28800000 |
The default number of seconds after which secure conversation session of re-authenticate use cases should expire. The reauthenticate lifetime session should usually have a larger value because the session is shared across multiple users. When reauthentication is true and the session is shared among many users, you can set this to a larger value. |
SecureConversation |
rm.encrypt.body |
false |
(Applies to web service client only.) Specifies whether the WS-RM protocol messages should be encrypted. If set to The response message body for protocol messages depends on the request message body: if the request message from the client is encrypted for protocol messages, the web service sends the response encrypted, and vice versa. |
You can use WLST to set domain-level message policy access for OWSM, including the ability to configure the Policy Manager connection for auto-discovery, and whether SSL should be used for the connection. You can also manage the policy cache and configure high availability by tuning the retry logic.
The configuration details are provided in the following sections:
You can use the setWSMConfiguration
command to configure the Policy Manager connection.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
For additional information about the Policy Manager connection, see "Understanding Configuring the Policy Manager Connection Using Fusion Middleware Control".
Table 14-9 lists the OWSM domain-level configuration properties that you can set for the Policy Manager connection.
Table 14-9 Policy Manager Connection Domain-Level Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
ConfigManager |
connect.retry.delay |
60000 |
Number of milliseconds to wait before the Agent attempts to establish a connection to the Policy Manager after a failure. |
ConfigManager |
keystore.csf.key |
keystore-csf-key |
CSF key to use to obtain credential of the keystore. Required for two-way SSL. |
ConfigManager |
keystore.path |
kss://owsm/keystore |
Keystore path relative to the domain configuration directory. If the keystore path is provided as If the keystore path is provided as Required for two-way SSL. |
ConfigManager |
keystore.ssl.alias |
mykey |
Keystore alias. Required for two-way SSL. |
ConfigManager |
keystore.type |
KSS |
Type of keystore. Default value is KSS. Required for two-way SSL. |
ConfigManager |
pm.csf.key |
CSF key to use to obtain a principal (and its credentials) authorized to access an OWSM Policy Manager instance. If not specified, then the OracleSystemUser principal (standard for WebLogic Server environments) is used. |
|
ConfigManager |
pm.url |
URL that specifies the location of the policy accessor. The following entries are valid:
Note: If you do not provide a value for |
|
ConfigManager |
refresh.repeat |
600000 |
Number of milliseconds to wait between configuration refreshes. |
ConfigManager |
ssl.twoway |
false |
Specifies if SSL connection should be one-way or two-way. Set to |
ConfigManager |
truststore.csf.key |
keystore-csf-key |
CSF key to use to obtain credential of the keystore. Required for one-way and two-way SSL. |
ConfigManager |
truststore.path |
kss://owsm/keystore |
Truststore path relative to the domain configuration directory. If the truststore path is provided as If the truststore path is provided as Required for one-way and two-way SSL. |
You can use the setWSMBootstrapConfig
command to update the bootstrap configuration document (domain_home/config/fmwconfig/wsm-config.xml
).
To do so, complete the following steps:
OWSM has background threads to refresh configuration and documents cache automatically at regular time intervals. This interval is specified in the following properties: refresh.repeatand cache.refresh.repeat. You can disable this automatic refresh by setting the value of configuration property auto.refresh to disabled. Then, you can invoke the WLST command refreshWSMCache() to refresh this cache manually when required.
The following topics explain this further:
You can disable the automatic refresh of OWSM cache by setting the value of the configuration property auto.refresh
to disabled
.
You can use the setWSMConfiguration
command to configure high availability and cache management.
The command is described in "Setting OWSM Domain Configuration Properties Using the setWSMConfiguration Command".
For more information about tuning the connection using these properties, see "High Availability Configuration and Cache Management Using Fusion Middleware Control".
Table 14-10 lists the OWSM domain-level configuration properties that you can set for high availability and cache management.
Table 14-10 High Availability and Cache Management Domain Configuration Properties
Category | Property Name | Default | Description |
---|---|---|---|
BeanAccessor |
cache.refresh.initial |
600000 |
The number of milliseconds to wait before initial cache refresh. Note: This property must have a value greater than or equal to 5 second. If the value is less than 5 second, then the property does not work as expected. |
BeanAccessor |
cache.refresh.repeat |
600000 |
The number of milliseconds to wait between cache refreshes Note: This property must have a value greater than or equal to 5 second. If the value is less than 5 second, then the property does not work as expected. A lower value will also overload the system. |
BeanAccessor |
failure.retry.count |
2 |
The number of times to retry after a communication failure. |
BeanAccessor |
failure.retry.delay |
5000 |
The number of milliseconds to wait between retry attempts. |
BeanAccessor |
jndi.connection.timeout |
30000 |
The number of milliseconds to wait before timing out for waiting for the connection to the configured Policy Manager using the java.naming.provider.url. |
BeanAccessor |
missing.retry.delay |
15000 |
The number of milliseconds to wait before trying to retrieve a missing document. |
BeanAccessor |
usage.record.delay |
30000 |
The number of milliseconds to wait before sending usage data. |