This chapter includes the following sections:
Configuring the Policy Manager Connection and Tuning the Policy Cache
Defining Trusted Issuers and a Trusted DN List for Signing Certificates
Configuring Oracle WSM with a Domain-Wide Administration Port
A key feature of the Web services model is the ability to make Web services widely available and discoverable. UDDI is one approach to publishing and discovery of Web services that centralizes information about businesses and their services in registries. Another emerging alternative standard is the Web Services Inspection Language (WSIL) specification.
Oracle Enterprise Manager Fusion Middleware Control provides support for registering Web services that are published in WSIL documents and UDDI v3 registries. Any service that is available in a WSIL document or a UDDI v3 registry can be registered within Enterprise Manager.
You can also register meta information, or a profile, for sources of services to help you manage your registered services within Enterprise Manager. Once you register a source and assign it a logical name, you do not need to specify connectivity information, such as a URL for a WSDL, in the future. A domain can have multiple registered sources, and each registered source can have multiple registered services. Once you register a source, you can easily look up services that you can register to the source.
Service names and corresponding WSDLs must be unique within a registered single source. Once you have registered a service, an attempt to register another service with the same name, or a different name but the same WSDL URL as another service, is not valid.
Once you register a Web service, you can later, more conveniently, reference the service from a selection list within Enterprise Manager. For example, when testing a Web service as described in "Testing Your Web Services", instead of specifying a WSDL, you can click the Search icon and then select the WSDL from the list of registered services, as shown in Figure 14-1.
Figure 14-1 Selecting From a Registered Service
Universal Description Discovery & Integration (UDDI) is an industry initiative that aims to enable businesses to quickly, easily, and dynamically find and carry out transactions with one another. A populated UDDI registry contains cataloged information about businesses; the services that they offer; and communication standards and interfaces they use to conduct transactions.
The owners of Web services publish them to the UDDI registry. Once published, the UDDI registry maintains pointers to the Web Service description and to the service. The UDDI allows clients to search this registry, find the intended service, and retrieve its details. These details include the service invocation point as well as other information to help identify the service and its functionality.
WSIL defines an Extensible Markup Language (XML) format for referencing Web service descriptions. These references are contained in a WSIL document, and refer to Web service descriptions (for example, WSDL files) and to other aggregations of Web services (for example, another WSIL document or a UDDI registry).
WSIL documents are typically distributed by the Web service provider. These documents describe how to inspect the provider's Web site for available Web services. Therefore, the WSIL standard also defines rules for how WSIL documents should be made available to consumers of Web services.
The WSIL model decentralizes Web service discovery. In contrast to UDDI registries, which centralize information on multiple business entities and services, WSIL makes it possible to provide Web service description information from any location. Unlike UDDI, WSIL is not concerned about business entity information, and does not require a specific service description format. It assumes that you know who the service provider is and relies on other standards for Web service description, such as WSDL.
Follow the steps in this section to view and edit a registered source and Web service.
In the navigator pane, expand WebLogic Domain to show the domain in which you want to view the registered sources and Web services.
Select the domain.
Using Fusion Middleware Control, select WebLogic Domain then Web Services and then Registered Services. The Registered Sources and Services page appears, as shown in Figure 14-2.
Figure 14-2 Viewing Registered Sources and Services
In the Sources table, you can view the following information about each registered source:
Name—Logical name for the source
Description—Description of the source
Source URL—Location of the source in URL format
Type—Source type: UDDI v3 registry import, WSIL import from file, WSIL import from URL
User ID—User ID for the external source
You can customize the information that is displayed using the View menu. From this section of the page, you can also add new sources, edit or delete sources, register Web services for a source, and publish a Web service from a source to a predefined UDDI registry.
Select a source in the Sources table.
Each registered source can have multiple registered services. In the Services table, you can view the following information about the registered services imported from the selected source location:
Name—Name of the registered service
Description—Description of the service
Service location—Location of the service in URL format
You can customize the information that is displayed using the View menu. You can also display the WSDL for the selected service and test the selected Web service.
You can register Web service sources of the following types:
UDDI v3 registry import
WSIL import from URL
WSIL import from file
Follow the steps in this section to register a source.
In the navigator pane, expand WebLogic Domain to show the domain in which you want to register a Web service source.
Select the domain.
Using Fusion Middleware Control, select WebLogic Domain then Web Services and then Registered Services. The Registered Sources and Services page appears, as shown in Figure 14-2.
Click Add to register a new source. The Register New Source page appears, as shown in Figure 14-3.
Enter the following information for the new source.
Name—A logical name for the source.
Description—A description of the source.
Type—choose from one of three options: UDDI v3 registry import, WSIL import from URL, or WSIL import from File
Additional information that you must enter differs based on the option you select.
If you selected UDDI v3 registry import, enter the following information:
In the Source URL field, enter the UDDI inquiry URL, for example, http://somehost/uddi/inquiry
.
To allow the services to be published to a UDDI source (which is an external UDDI registry), select the Enable box and complete the fields as follows:
In the Publication URL field, enter URL location of the registry to which you want to publish the service.
In the Security URL field, enter the URL location of the security port required to access the registry.
In the User ID and Password fields, enter the security credentials required to access the registry.
If you selected WSIL import from URL, enter the following information:
In the Source URL field, enter the location of the WSIL in URL form.
If a username and password are required to access the WSIL, select the Enable box in the Basic Authorization field. In the User ID and Password fields, enter the username and password.
If you selected WSIL import from File, click Browse (next to the WSIL File field) to select the WSIL file to be imported.
Click OK to register the source.
Follow the steps in this section to register Web services from a registered UDDI source.
In the navigator pane, expand WebLogic Domain to show the domain in which you want to register a Web service.
Select the domain.
Using Fusion Middleware Control, select WebLogic Domain then Web Services and then Registered Services. The Registered Sources page displays, as shown in Figure 14-1.
Select the UDDI source from which you want to register services. Note that the Type for a UDDI source is specified as UDDI v3 registry import.
Select Register Web Services.
The Register New Service page displays, as shown in Figure 14-4.
Figure 14-4 Register New Service from UDDI Source
The Register New Service page displays the source information, in read-only format, and a list of the services that are available in UDDI that you can register.
You can filter the list of available services that are displayed using the Service Name and Service Key fields. For example, to find calculator services, enter calc
in the Service Name field. Only services that contain the calc
string, such as calculator services are displayed. The search is not case-sensitive.
In the Services available in UDDI section of the page, you can view service details from UDDI for each service in the table by clicking the View Service Details icon. The Service Details from UDDI window displays information about the service such as the Service Name, Service Description, Service WSDL, Service Key, Business Key, and Service Location, among others.
You can edit the details of a service by clicking the Edit icon, which allows you to change the name and description of the selected service.
In the Services available in UDDI section of the page, select the service or services that you want to register from the source and click Register.
A confirmation message displays indicating that the service was registered successfully.
Follow the steps in this section to register Web services from a registered WSIL source.
In the navigator pane, expand WebLogic Domain to show the domain in which you want to register a Web service.
Select the domain.
Using Fusion Middleware Control, select WebLogic Domain then Web Services and then Registered Services. The Registered Sources and Services page displays, as shown in Figure 14-1.
Select the WSIL source from which you want to register services. Note that the Type for a WSIL source is specified as either WSIL import from File or WSIL import from URL.
Select Register Web Services.
The Register New Service page displays, as shown in Figure 14-5.
Figure 14-5 Register New Service from WSIL Source
The Register New Service page displays the Source information, in read-only format, and a list of available services, if any, in the WSIL that you can register, shown in the Services Available in WSIL table. If there are any WSIL references in the WSIL, they are listed in the References Available in WSIL table.
In the Services Available in WSIL table, you can edit the details of a service by clicking the Edit icon, which allows you to change the name and description of the selected service.
To register a service available from the current WSIL, select the service in the Services Available in WSIL table and click Register.
A confirmation message displays indicating that the service was registered successfully.
If the current WSIL also references other WSIL URLs or references, expand References Available in WSIL to display them. You can register the referenced Web services as well.
To register a service from a referenced WSIL instead of the current WSIL, click the Process icon for the reference in the References Available in WSIL table.
If the WSIL parses successfully, a new source is registered and the current WSIL source is replaced by the referenced WSIL. The services available in the referenced WSIL source are listed in the Services Available in WSIL table. You can then register services from the referenced WSIL.
Note:
For each new source created,_n
is appended to the parent source name. For example, if the parent source name is wsil_file_1
, then referenced new sources are named wsil_file_1
_1
, wsil_file_1
_2
) with source type WSIL URL. The new sources are listed in the Sources table in the Registered Sources and Services page.If the WSIL does not parse successfully, an error message displays. Usually, in such cases, the system successfully registers the new source for the selected WSIL reference. However, because the system could not parse the WSIL document, the error message displays. Close the error dialog and click OK to return to the Registered Sources and Services page.
WSIL parsing can fail if the reference is bad or it needs authorization credentials. You can enable authorization for the WSIL source as described in "Registering a Source".
Note:
When the system fails to retrieve Web services from a registered source, because of connection or other failures, the Register New Service page is displayed with read only information for the source, but does not show any Web services. In such cases, click OK in the error dialog, if an error dialog is displayed, then click OK in the Register New Service page to return to the Registered Sources and Services page. To troubleshoot, you can then view the registered sources through other means. For example, if the source is a:
WSIL URL source, copy the URL to a browser address bar to view its contents.
WSIL file source, examine the WSIL file using an XML editor.
UDDI source, try to access the UDDI registry directly to investigate.
You can also review any related Enterprise Manager error logs.
Follow the steps in this section to delete a Web service or a Web service source.
In the navigator pane, expand WebLogic Domain to show the domain in which you want to delete a Web service.
Select the domain.
Using Fusion Middleware Control, select WebLogic Domain then Web Services and then Registered Services. The Registered Sources and Services page displays, as shown in Figure 14-2.
Do one of the following:
To delete a source, select the source from the Sources table and click Delete.
A confirmation message displays. Click OK to delete the source.
To delete a service from a source, select the source in the Sources table.
The registered Web services are displayed in the Services table.
Select the service to be deleted from the Services table and click Delete.
A confirmation message displays. Click OK to delete the service.
You can publish Web services to UDDI from a registered UDDI source and from the Web services summary page for ADF, WebCenter, and Java EE applications. Registered UDDI sources are listed in the Registered Sources and Services page, which includes all sources and services registered in a domain. The Web services summary page lists the Web services in an application.
Notes:
You must use a proxy to publish a service to UDDI, since this requires access to URLs outside of your firewall. For more information about the required proxy settings, see "Configuring the Proxy Server for UDDI".If your services are already in Oracle Enterprise Repository (OER) then you should use the OER Exchange Utility to publish those services to Oracle Service Registry.
The following procedures describe how to publish Web services to UDDI.
To publish a Web service to UDDI from a registered source:
Navigate to the Registered Sources and Services page as described in "Viewing Registered Sources and Web Services".
Select the source row in the Sources table and then Publish to UDDI.
Figure 14-6 Registered Sources and Services Page with Publish to UDDI Selected
In the Publish Service to UDDI window, enter the information about the service to be published:
Service Name is the name of the Web service to be published to the UDDI registry. This field is required.
Service Description is a description of the selected Web service.
Service Definition Location is the URL location of the service definition. This field is required.
UDDI Source is the name of the UDDI source from which the service is to be registered. This field is read only.
Business Name is the name of the data structure in the UDDI registry. It is assumed that the business has already been registered in the UDDI. Choose the Business name from the list. This field is required.
Figure 14-7 Publish Service to UDDI Window from a UDDI Source
Click OK in the Publish Service to UDDI window.
The system verifies that the service specified has a valid WSDL and that the UDDI registry has accepted the new entry or updated an existing one. If it is successful, a confirmation message displays and the service is published to the registry. Once the service is published in the UDDI, it becomes available to be registered to a source, as described in "Registering Web Services from a UDDI Source".
Any errors during the operation will result in an error message.
Note that you can only register the service to a source if it uses a unique WSDL.
To publish a Web service to UDDI from an application:
Navigate to the Web Services summary page as described in "Navigating to the Web Services Summary Page for an Application".
From the Web Service Details section of the page, select the service to be published.
Select Actions, then Publish to UDDI. See Figure 14-8.
Figure 14-8 Web Services Summary Page with Publish to UDDI Selected
In the Publish Service to UDDI dialog box (Figure 14-9), enter the information about the service to be published:
Service Name is the name of the Web service to be published to the UDDI registry. This field is required.
Service Description is a description of the selected Web service.
Service Definition Location is prepopulated with the URL location of the service definition (This field is read-only.)
UDDI Source is a logical name for the UDDI registry source. Choose the UDDI source from the list. This field is required.
Note:
The list contains the UDDI sources registered in the domain that have been enabled for publishing. For more information about registered sources, see "Registering Web Services and Sources".Business Name is the name of the data structure in the UDDI registry. It is assumed that the business has already been registered in the UDDI. Choose the business name from the list. This field is required.
Figure 14-9 Publish Service to UDDI Dialog Box
Click OK to connect to the external UDDI registry and register the Web service.
Upon successfully registering the service, a confirmation message displays. Any errors during the operation will result in an error message.
To access URLs outside of your firewall, you must use a proxy to publish a service to UDDI.
Before starting Oracle WebLogic, you must set the Java system properties defined in Table 14-1. You can set them as environment variables, or in Oracle WebLogic startup files.
Table 14-1 Java System Properties Used to Specify the Proxy Server for UDDI
Property | Description |
---|---|
proxySet=true |
Flag that specifies that the WebLogic proxy properties should be used. |
http.proxyHost=proxyHost |
Name of the host computer on which the proxy server is running. |
http.proxyPort=proxyPort |
Port to which the proxy server is listening. |
http.nonProxyHosts=hostname | hostname | ... |
List of hosts that should be reached directly, bypassing the proxy. Separate each host name using a | character. |
For example:
set PROXY_SETTINGS="-DproxySet=true -Dhttp.proxyHost=www-proxy.example.com -Dhttp.proxyPort=80 -Dhttp.nonProxyHosts=localhost|${HOST}|*.example.com"
Auditing describes the process of collecting and storing information about security events and the outcome of those events. An audit provides an electronic trail of selected system activity.
An audit policy defines the type and scope of events to be captured at run time. Although a very large array of system and user events can occur during an operation, the events that are actually audited depend on the audit policies in effect at run time. You can define component- or application-specific policies, or audit individual users.
You configure auditing for system components, including Web services, and applications at the domain level using the Audit Policy page. You can audit SOA, ADF, and WebCenter services.
The audit policies table, at the center of the page, displays the audits that are currently in effect. The table includes the following information:
Name—Name of the system components and applications that you can audit.
Enable Audit—Identifies the components and applications for which auditing is currently in effect.
Filter—Specifies any filters that are currently in effect.
The following table summarizes the events that you can audit for Web services and the relevant component.
Table 14-2 Auditing Events for Web Services
Enable auditing for the following Web service events . . . | Using this system component . . . |
---|---|
|
Oracle Web Services Manager—Agent |
|
Oracle Web Services |
|
Oracle Web Services Manager—Policy Manager Note: The Policy Manager audits both direct policy attachments and global policy attachments for policy sets. |
|
Oracle Web Services Manager—Policy Attachment Note: The Policy Attachment audits only direct policy attachments. |
You can also audit the events for a specific user, for example, you can audit all events by an administrator.
For more information about configuring audit policies, see "Configuring and Managing Auditing" in Oracle Fusion Middleware Application Security Guide.
The following sections describe how to define audit policies and view audit data:
Follow the steps in this section to configure audit policies.
In the Navigator pane, expand WebLogic Domain.
Click the domain for which you want to manage assertion templates.
From the WebLogic Domain menu select Security > Audit Policy.
The Audit Policy Settings page is displayed.
Select and audit level from the Audit Level menu.
Valid audit levels include:
None—Disables auditing.
Low—Audits a small scope of events. The subset of events is predefined individually for each component. For example, for a given component, Low may collect authentication and authorization events only.
Medium—Audits a medium scope of events (which is a superset of the events collected at the Low level). For example, for a given component, Medium may collect authentication, authorization, and policy authoring events.
Custom—Enables you to provide a custom auditing policy.
You can view the components and applications that are selected for audit at each level in the audit policies list. For all audit levels other than Custom, the information in the audit policies list is greyed out, as you cannot customize other audit level settings.
If you selected the Custom audit level, perform one of the following steps:
Select the information that you want to audit by clicking the associated checkbox in the Enable Audit column.
You can audit at the following levels of granularity: All events for a component, all events within a component event group, an individual event, or a specific outcome of an individual event (such as success or failure).
At the event outcome level, you can specify an edit filter. Filters are rules-based expressions that you can define to control the events that are returned. For example, you might specify an Initiator as a filter for policy management operations to track when policies were created, modified, or deleted by a specific user. To define a filter for an outcome level, click the Edit Filter icon in the appropriate column, specify the filter attributes, and click OK. The filter definition appears in the Filter column.
Deselect the checkbox for a component at a higher level to customize auditing for its subcomponents. You can select all components and applications by checking the checkbox adjacent to the column name.
To audit only failures for all system components and applications, Select Failures Only.
If selected, all checkboxes in the Enable Audit column are cleared.
If required, enter a comma-separated list of users in the Always Audit Users text box.
Specified users will always be audited, regardless of whether auditing is enabled or disabled, and at what level auditing is set.
Click Apply.
To revert all changes made during the current session, click Revert.
To manage the data collection and storage of audit information, you must perform the following tasks:
Set up and manage an audit data repository.
You can store records using one of two repository modes: file and database. It is recommended that you use the database repository mode. The Oracle Business Intelligence Publisher-based audit reports only work in the database repository mode.
Set up audit event collection.
For more information, see "Managing the Audit Store" in Oracle Fusion Middleware Application Security Guide.
For database repositories, data is exposed through pre-defined reports in Oracle Business Intelligence Publisher.
A number of predefined reports are available, such as: authentication and authorization history, Oracle WSM policy enforcement and management, and so on. For details about generating and viewing audit reports using Oracle Business Intelligence Publisher, see "Using Audit Analysis and Reporting" in Oracle Fusion Middleware Application Security Guide.
For file-based repositories, you can view the bus-stop files using a text editor and create your own custom queries.
In some cases, you might not want the Web service WSDL to be accessible to the public. You can enable or disable public access to the WSDL from the Web Service Endpoint page.
Note:
In some cases, a Web service client needs to access a WSDL during invocation. If public access to the WSDL is disabled, the client must have a local copy of the WSDL.Navigate to the Web Service endpoint configuration page, as described in "Configuring the Web Service Endpoint".
On the Configuration tab, set the WSDL Enabled field to True or False to enable of disable public access to your WSDL, respectively.
Click Apply.
Security policies can be attached to a running client using Oracle Enterprise Manager Fusion Middleware Control. You do not have to redeploy the client application to attach or detach policies from the client. See Chapter 8, "Attaching Policies to Web Services" for more information on how to attach policies using Fusion Middleware Control.
You can manage properties for the following components from the Platform Policy Configuration page:
Policy Accessor
Policy Cache
Policy Interceptors
Identity Extension
Trusted SAML clients
Trusted STS servers
To manage policy accessor, policy cache, policy interceptor, and identity extension properties:
In the navigator pane, expand WebLogic Domain to view the domains.
Select the domain for which you want to manage properties.
Select WebLogic Domain> Web Services > Platform Policy Configuration.
The Platform Policy Configuration page appears, as shown in Figure 14-11.
Figure 14-11 Platform Policy Configuration Page
Select the tab corresponding to the component for which you want to define properties:
By default, the Oracle Web Services Manager (WSM) supports an auto-discovery feature that it uses to locate and connect to an Oracle WSM Policy Manager within the same WebLogic domain. In certain scenarios auto-discovery may not work as expected.
Note:
When the Oracle WSM Policy Manager is deployed on a server that is configured to use SSL, the auto-discovery mechanism will only attempt to connect to Policy Managers on other SSL-configured servers. To ensure that the secure connection is maintained, Policy Managers deployed on servers that are not configured for SSL are ignored.You may want to disable the auto-discovery feature, for example, 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.
For Oracle Infrastructure Web service policies, on the Platform Policy Configuration page:
The Policy Accessor tab enables you to specify an alternate Policy Manager URL and corresponding credentials to access the Policy Manager.
The Policy Cache tab allows you to tune the behavior of the policy cache delay for Web service endpoints, which can help to avoid network calls and increase performance when fetching policies from the Policy Manager.
To configure a Policy Manager connection and tune the policy cache:
Access the Platform Policy Configuration page, as described in "Configuring Platform Policy Properties".
Select the Policy Accessor tab.
Click Add to define a JNDI provider.
In the Add Property window, specify the following values:
In the Name field, enter the JNDI provider URL property as java.naming.provider.url
.
In the Value field, enter the JNDI provider's URL, for example t3://
host
:
port
.
Click OK.
Click Add to define a corresponding csf-key credential property. In the Add Property window, specify the following values:
In the Name field, enter the name of the JNDI provider's csf-key credential property as jndi.lookup.csf.key
.
In the Value field, enter the csf-key credentials.
Because the Policy Manager is security enabled, the csf-key specifies the java.naming.security.principal
and java.naming.security.credentials
when using the JNDI URL to look up a Policy Manager.
Click OK.
For more information on storing, retrieving, and deleting credentials, see "Adding Keys and User Credentials to the Credential Store"
Select the Policy Cache tab.
To modify the policy cache property for Web service endpoints, select it and then click Edit. In the Edit Property window, you can edit the Value field to change the default amount for each property.
cache.tolerance
– Amount of time (in milliseconds) between refreshes of the policy cache. This ensures that the policy set retrieved from the Web service endpoint policy cache is the most current version (that is, it has not exceeded the cache.tolerance
value). If it is determined that the policy set is stale, the updated policy set is retrieved from the Oracle WSM Policy Manager and refreshed in the Web service endpoint policy cache. The default is 60000 milliseconds (1 minute).
Note: The refresh delay amount for Web service endpoints is aggregated with the value of the cache.refresh.repeat
property on the Policy Accessor tab for the Oracle WSM Policy Manager. Therefore, you should verify whether this additional value produces the desired refresh delay when combined with the cache.refresh.repeat
amount. For more information, see "Tuning WSM Repository Connections".
To add another property, click Add, and in the Add Property window, specify the necessary values.
Click OK.
To modify an existing property, select it and then click Edit.
To delete an existing property, select it and then click Delete.
Click Apply to apply the property updates.
The Policy Accessor tab also enables you to configure the retrieval of Oracle WebLogic Web service policies from a repository. This includes specifying the repository location (JARs, directory, or host and port) and the account information.
Access the Platform Policy Configuration page, as described in "Configuring Platform Policy Properties".
Select the Policy Accessor tab.
Click Add to add a policy retrieval property.
Use the following table to specify the property names and values in the Add New Configure Property window:
Table 14-3 Properties in Add Property Window
Element | Description |
---|---|
java.naming.provider.url |
JNDI URL that specifies the location of a running Oracle WSM Policy Manager, for example |
jndi.lookup.csf.key |
If the location of the Oracle WSM Policy Manager is provided in the You should configure this property when:
For more information on modifying the default user, see "Modifying the Default User". |
To modify an existing property, select it and then click Edit.
To delete an existing property, select it and then click Delete.
Click Apply to apply the property updates.
The properties on the Policy Accessor tab also enable you to configure the connection between the Agent and the Oracle WSM Policy Manager, including retry logic (for high availability), and cache refresh rates.
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.
If the initial connection is made, but the Oracle WSM 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 cache.refresh.initial
and cache.refresh.repeat
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.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.retry.delay
property will still affect how often it attempts to communicate with the Policy Manager until it is fixed.
To view or change the settings for these properties:
Access the Platform Policy Configuration page, as described in "Configuring Platform Policy Properties".
Select the Policy Accessor tab.
Select the property in the table and click Edit.
Table 14-4 lists the available properties and their default settings.
Table 14-4 Properties for Tuning WSM Repository Connections
Property | Description | Default |
---|---|---|
|
Number of milliseconds to wait before the Agent attempts to establish a connection to the Policy Manager after a failure. |
600000 milliseconds (10 minutes) |
|
Number of milliseconds to wait before initial cache refresh. |
600000 milliseconds (10 minutes) |
|
Number of milliseconds to wait between cache refreshes. |
600000 milliseconds (10 minutes) |
|
Number of milliseconds to wait before trying to retrieve a missing document. |
15000 milliseconds |
|
Number of milliseconds to wait before sending usage data. |
30000 milliseconds |
|
Number of times to retry after communication failure. |
2 retry attempts |
|
Number of milliseconds to wait between retry attempts. The default is 5000 milliseconds. |
Enter the changes required and click OK.
Edit any remaining properties as desired and then click Apply to apply the property updates.
The BindingSecurityInterceptor
property on the Policy Interceptors tab allows you to tune 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.
Perform the following steps to tune the security policy enforcement:
Access the Platform Policy Configuration page, as described in "Configuring Platform Policy Properties".
Select the Policy Interceptors tab.
Select the BindingSecurityInterceptor
security property on the list.
Table 14-5 list the properties that you can set to tune Web service security policy enforcement.
To modify a BindingSecurityInterceptor
security property, select it and then click Edit. In the Edit Property window, you can edit the Value field to change the default amount for each property and click OK.
Table 14-5 Properties for Tuning Web Service Security Policy Enforcement
Property | Description | Default |
---|---|---|
|
Tolerance of time differences, in seconds, 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. Increase
|
|
|
Tolerance of time, in seconds, that is used to calculate the Note: This property does not appear in the BindingSecurityInterceptor Interceptor Properties table by default. To modify the property value, add the property to the table by clicking Add, setting the Name field to agent.client.clock.skew and the Value field to the desired value, and clicking OK. |
|
|
Total time-to-live, in seconds, 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. Note: For username token settings, you must enable both the Creation Time Required and Nonce Required properties to prevent replay attacks. If only Nonce Required is enabled, then nonce will be cached forever to prevent replay attacks. Additionally, you must set the value of |
|
|
Duration of time, in seconds, 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. If the message expires when received by the service even when there is no time difference between the client's and service's clocks, then the message expiry time must be increased. The message expiry time is derived from the values of |
|
|
Property that specifies whether Oracle WSM will accept all types of XPath transformations. By default, Oracle WSM only accepts the XPath transformation Note: Enabling this property may result in XPath-based Denial of Service attacks or other similar XPath based security vulnerabilities. |
|
To delete an existing property, select it and then click Delete.
Click Apply to apply the property updates.
The properties on the Identity Extension 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 certificate is published, you can also specify whether to ignore the hostname verification feature.
For more information, see "Using Service Identity Certification Extension".
In Fusion Middleware Control, the Trusted SAML clients and Trusted STS servers tabs enable you to define SAML trusted issuers and a list of trusted distinguished names (DNs) for SAML signing certificates.
Note:
You can define JWT, as well as SAML trusted issuers, using WLST as described in "Defining Trusted Issuers and Managing DN Lists Using WLST".This is the preferred method of adding trusted issuers. The list of trusted issuers that you define here 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.
Note:
There is a hierarchy that determines how trusted issuers are determined:The list of trusted issuers configured for policies (or overridden) is checked and used, as specified by the saml.trusted.issuers
property for the policy. For example, see saml.trusted.issuers
in Table C-32, "wss10_saml20_token_service_template Configurations".
If not configured for policies (or overridden), the configuration at the platform policy configuration as described in this section is checked and used.
If the list of trusted issuers is not configured for policies (or overridden) or configured at the platform policy configuration, only then is the Issuers list defined in the SAML login module used. For more information about the Issuers list defined in the SAML login module, see Step 4 in "Configuring the SAML and Kerberos Login Modules".
By default, Oracle WSM checks the incoming issuer name against the list of configured issuers, and checks the SAML signature against the configured certificates in the Oracle WSM keystore. If you define a trusted DNs list, Oracle WSM also verifies that the SAML signature is signed by the particular certificate(s) that is associated with that issuer.
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 Oracle WSM allows signing by any certificate, as long as that certificate is trusted by the certificates present in the Oracle WSM keystore.
Important Notes:
Using the Trusted SAML clients and Trusted STS servers tabs, or the associated WLST commands, you define the DNs of the signing certificates, not the certificates themselves.
The certificate must be imported into the Oracle WSM keystore or included in the message. If the certificate is provided in the message, its issuer must be imported into the Oracle WSM keystore.
For two-way SSL:
The certificate needs to be imported into the Java EE container's trust store.
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.
You can define trusted issuers and DN lists using Fusion Middleware Control or WLST.
To define a trusted DN list for a SAML signing certificate:
Access the Platform Policy Configuration page, as described in "Configuring Platform Policy Properties".
Select the Trusted SAML clients or Trusted STS servers tab, depending on whether you want to define a trusted DNs list for trusted SAML clients or trusted STS servers. (For SAML sender vouches, the trusted SAML client list is used. For HOK and bearer, the trusted STS server list is used.) See Figure 14-12.
Figure 14-12 Adding Trusted Issuers on the Platform Policy Configuration Page
Add one or more trusted issuers within the Trusted Issuers section of the page.
The default value is www.oracle.com
.
Click Add to add a new trusted issuer. For example: www.yourcompany.com
.
Select the trusted issuer for which you want to define a DN list in the Trusted Issuers section of the page.
Click Add to add one or more trusted DNs in the Trusted SAML clients or Trusted STS servers area of the page. Use a string that conforms to RFC 2253. For example: CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US
for the trusted issuer www.oracle.com
.
For more information about RFC 2253, see http://www.ietf.org/rfc/rfc2253.txt
.
The following sections describe how to use WLST commands to define trusted issuers and a list of trusted distinguished names (DNs) for SAML signing certificates and JWT tokens, and how to display and manage the lists associated with a trusted issuer.
To configure trusted issuers and DN lists using WLST:
Connect to the running instance of the server in the domain for which you want to configure the trusted issuers as described in "Accessing the Web Services Custom WLST Commands".
Add the trusted issuers and define trusted keys or a trusted DN list using the setWSMTokenIssuerTrust
command.
setWSMTokenIssuerTrust(type, issuer, [trustedKeyIds=None])
In this command:
type
indicates the types of the tokens issued by the issuer and how the issuer signing certificates are identified with trustedKeyIds. Supported type values are shown in the following table.
Use this type value... | For this token type... | With this key type... | And this key identifier type |
---|---|---|---|
dns.sv |
SAML SV | X509 certificate | DN |
dns.hok |
SAML HOK or Bearer | X509 certificate | DN |
dns.jwt |
JWT | X509 certificate | DN |
issuer
is the name of the trusted issuer, such as www.oracle.com
.
trustedKeyIds
is an optional argument used to specify the trusted key identifiers or DN list for the issuer.
This command behaves as follows:
If the trusted issuer already exists for the type specified, and you provide a list of DNs for the trustedKeyIds
argument, the previous list is replaced with the new list. If you enter an empty set ([]
) for the trustedKeyIds
argument, then the list of DN values are deleted for the issuer.
If the trusted issuer does not exist for the type specified and you specify a value for the trustedKeyIds
argument, the issuer is created with the associated DN list. If you do not set the trustedKeyIds
argument, a new issuer is created with an empty DN list.
In Example 14-1, www.yourcompany.com
is set as a trusted issuer for a SAML SV token type. A DN list is not specified.
Example 14-1 Setting a Trusted Issuer for SAML Sender Vouches Token Using WLST
wls:/base_domain/serverConfig> setWSMTokenIssuerTrust("dns.sv","www.yourcompany.com",[])
the trusted DN lists are successfully set
In Example 14-2, CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US'
and CN=orcladmin, OU=Doc, O=Oracle, C=US'
are set as DNs in the dns.sv
DN list for the www.oracle.com
trusted SAML issuer.
Example 14-2 Setting DNs for SAML Trusted Issuer Using WLST
wls:/base_domain/serverConfig> setWSMTokenIssuerTrust('dns.sv','www.oracle.com', ['CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle', 'CN=orcladmin, OU=Doc, O=Oracle, C=US']) the trusted DN lists are successfully set
In Example 14-3, www.newcompany.com
is set as a trusted issuer for a JWT token type with a trusted DN of CN=weblogic1, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US'
.
Optionally, you can add additional security constraints by defining token attribute rules for a trusted DN. For more information, see "Configuring Token Attribute Rules for Trusted Issuers Using WLST".
To display the trusted issuers and DN lists using WLST:
Connect to the running instance of the server in the domain for which you want to display the trusted issuers as described in "Accessing the Web Services Custom WLST Commands".
Display the trusted issuer and DN list using the displayWSMTokenIssuerTrust
command.
displayWSMTokenIssuerTrust(type, issuer=None)
When you specify a value for the type
and issuer
arguments, the DN lists for the issuer are displayed. If you do not specify an issuer name, all of the trusted issuers for the given type are listed. Supported values for the type
argument are dns.sv
, dns.hok
, and dns.jwt
.
For example, to view all of the trusted issuers for the type dns.sv
:
wls:/base_domain/serverConfig> displayWSMTokenIssuerTrust('dns.sv')
Starting Operation displayWSMTokenIssuerTrust ...
www.yourcompany.com
www.oracle.com
To view the DN lists for the www.oracle.com
trusted issuer for the type dns.sv
:
wls:/base_domain/serverConfig> displayWSMTokenIssuerTrust('dns.sv', 'www.oracle.com')
Starting Operation displayWSMTokenIssuerTrust ...
CN=weblogic, OU=Orakey Test Encryption purposes only, O=OracleCN=orcladmin, OU=Doc, O=Oracle, C=US
You can delete a trusted issuer and its DN list by using the deleteWSMTokenIssuerTrust
WLST command:
deleteWSMTokenIssuerTrust(issuer, type)
Supported values for the type
argument are dns.sv
, dns.hok
, and dns.jwt
.
In the following example, the issuer www.yourcompany.com
plus the DN lists in the dns.sv
trusted SAML sender vouches client list for the issuer, if any, are deleted:
deleteWSMTokenIssuerTrust('dns.sv', 'www.yourcompany.com')
There are increasing requirements to control which users and user attributes are accepted and processed for a particular trusted user. Token attribute rules allow you to define additional security constraints for the trusted STS (Secure Token Service) server and for the trusted SAML or JWT client.
Token attribute rules can be defined on top of a trusted DN list. 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 signing certificate can assert. The name ID and the attribute can contain a filter with multiple value patterns. Procedures are provided in the following sections:
Configuring Token Attribute Rules for Trusted Issuers Using Fusion Middleware Control
Configuring Token Attribute Rules for Trusted Issuers Using WLST
To configure token attribute rules using Fusion Middleware Control, follow these steps:
Define a DN list. For information on defining a DN list in Fusion Middleware Control, see "Defining Trusted Issuers and a Trusted DN List for Signing Certificates".
To define a token attribute rule, select the Trusted SAML clients tab or the Trusted STS servers tab.
Select an Issuer in the top panel, then select a DN in the bottom panel, as illustrated in Figure 14-13.
Figure 14-13 Trusted Issuer and Trusted SAML Clients
Click Configure Token Attribute Rule to open the Token Attribute Rule window, as shown in Figure 14-14.
In the Attribute pane, click Add to add an attribute for the DN.
In the Token Attribute Rule: Add Attribute popup, enter name-id
to assert a Subject name ID and click OK.
Select the attribute and, in the Filters pane, click Add to enter a filter value in the Token Attribute Rule: Add Filter Value popup and click OK.
The value that you add in the Filter field can be a complete name, such as yourTrustedUser
as illustrated in Figure 14-15. You can also enter a name pattern with a wildcard character (*
), such as yourTrusted*
.
Figure 14-15 A Populated Token Attribute Page
Repeat the previous step to add additional filters.
When you have finished defining the attribute filters, click OK to close the Token Attribute Rule window.
You can add additional security constraints by using the setWSMTokenIssuerTrustAttributeFilter
WLST command to define token attribute rules for a trusted DN. The attribute rule can be applied to a subject name ID.
Note:
You must first use thesetWSMTokenIssuerTrust
command to configure a list of trusted DN names for an issuer. See "Configuring an Issuer and its DN List Using WLST".setWSMTokenIssuerTrustAttributeFilter(dn, attr-name, [filters])
In the following example, the name ID yourTrustedUser
is set as a trusted user for the weblogic
trusted DN:
setWSMTokenIssuerTrustAttributeFilter('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US','name-id', ['yourTrustedUser']) Starting Operation setWSMTokenIssuerTrustAttributeFilter ... The token attribute filter are successfully set
In the following example, the name ID jdoe
is added to the list of trusted users for the weblogic
trusted DN:
setWSMTokenIssuerTrustAttributeFilter('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US','name-id', ['yourTrustedUser', 'jdoe']) Starting Operation setWSMTokenIssuerTrustAttributeFilter ... The token attribute filter are successfully set
In the following example, the list of trusted users for the weblogic
trusted DN is removed:
setWSMTokenIssuerTrustAttributeFilter('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US', 'name-id', []) The token attribute filter are successfully set
You can delete a token attribute rule associated with a DN list by using the deleteWSMTokenIssuerTrustAttributeRule
WLST command:
deleteWSMTokenIssuerTrustAttributeRule(dn)
In the following example, the token attribute rule associated with the weblogic
trusted DN is deleted.
deleteWSMTokenIssuerTrustAttributeRule('CN=weblogic, OU=Orakey Test Encryption Purposes Only, O=Oracle, C=US')
You can create a token attribute rule to support client-side identity/attribute mapping for user-identity propagation with SAML/JWT tokens.
Consider the cross-identity-domain use case, in which a common user attribute such as email might be more conveniently used as the subject in the token. This requires mapping the authenticated Subject principal to a user attribute to create tokens. To do this, you create a token attribute rule to specify and manage the mappings for various targets.
User identity mapping is supported for identity propagation for end users for all the client policies with SAML or JWT tokens for SOAP or REST when the following is true:
The authenticated user Subject is available.
The property subject.precedence=true
.
You use the setWSMTokenIssuerTrustAttributeMapping
WLST command to configure client identity mapping. For more information about this WLST command see "Web Services Custom WLST Commands" in the WebLogic Scripting Tool Command Reference.
setWSMTokenIssuerTrustAttributeMapping('http://oracle.com', 'name-id', ’', ’mail')
where:
http://oracle.com
is the identifier of the rule, which is a URL pattern, for the token attribute rule for which modifications are done.
name-id
indicates that the mapping is applied to the Subject name id
for the out-going SAML/JWT token.
Blank. Optional. The name of the local user attribute the value of the attribute corresponds to.
mail
is the name of the local user attribute to map to.
The identifier is a URL pattern. Given a service URL, a token attribute rule applies to it if its identifier is part of the service URL.
http(s)://host; http(s)://host/<root path>
The mapping rule applies to all web service invocations for which the target service URL has the identifier as the root.
URL u1
is considered part of a URL u2
if:
The protocol for u1
and u2
match.
The host for u1
and u2
match.
If the path in u1
is available, then the path in u2
starts with the path in u1
.
If multiple rules (rule-1, rule-2, …, rule-n) apply to a service URL, then the rule whose identifier has the identifiers of all the other rules takes precedence among the rules.
Assume you have the following two rules:
Rule 1: setWSMTokenIssuerTrustAttributeMapping('http://oracle.com', 'name-id', ' ', 'mail') Rule2: setWSMTokenIssuerTrustAttributeMapping('http://oracle.com/root1', 'name-id', ' ', 'uid')
For a web service call with a service URL = http://oracle.com/root1/service1
, both Rule 1
and Rule 2
apply to the service. However, Rule 2
takes precedence and is enforced at runtime.
When your domain is configured to use an administration port, all tasks performed by administrators must go through this port. By default, the Oracle WSM Policy Manager is targeted to a Managed Server. To use the Policy Manager with an administration port, you must target the Policy Manager to the Managed Server and the Administration Server.
For more information about the administration port, refer to the following topics:
"Understanding Network Channels" in Configuring Server Environments for Oracle WebLogic Server.
"Configure the domain-wide administration port" in Oracle WebLogic Server Administration Console Help.
Configuring Oracle WSM with a domain-wide administration port requires two main steps:
Step 1. Use the WebLogic Administration Console to target the Policy Manager to the Administration Server.
Access the WebLogic Administration Console as described in "Accessing Oracle WebLogic Administration Console".
You can also access the WebLogic Administration Console from the WebLogic Domain Home page in Fusion Middleware Control as follows:
Log in to Fusion Middleware Control as described in "Accessing Oracle Enterprise Manager Fusion Middleware Control".
In the navigator pane, expand WebLogic Domain and select the domain for which you want to access the Administration Console.
The WebLogic Domain home page is displayed.
From the WebLogic Domain menu, select WebLogic Server Administration Console. Alternatively, you can click the Oracle WebLogic Server Administration Console link in the Summary section of the page.
In the Welcome page, log in using a valid username and password.
In the left pane of the Console, click Deployments. A table in the right pane displays all deployed Enterprise Applications and Application Modules.
In the table, locate the wsm-pm application you want to re-target and click on its name. You may have to click Next several times to find the application.
The Settings page for the application is displayed.
Click the Targets tab.
The servers to which the Policy Manager application is targeted are shown in the Current Targets column of the table.
To target the wsm-pm application to the AdminServer, click Change Targets.
In the Servers box, select AdminServer if it is not already selected and click Yes.
The changes are activated automatically.
Step 2. Use Fusion Middleware Control to specify the policy accessor URL for the Policy Manager on the Administration Server.
Access the Platform Policy Configuration page, as described in "Configuring Platform Policy Properties".
Select the Policy Accessor tab.
Click Add to specify the JNDI provider URL for the Administration Server.
In the Add Property window, specify the following values:
In the Name field, enter the JNDI provider URL property as java.naming.provider.url
.
In the Value field, enter the JNDI provider's URL for the Administration Server, such as t3s://
host
:
admin_port
/wsm-pm
.
For example, t3s://localhost:9002/wsm-pm
.
This specifies the location of a running Policy Manager running on the Administration Server.
Click OK.
To protect against replay attacks, the wss_username_token_client_policy
and wss_username_token_service_policy
policies provide the option to require a nonce in the username token. A nonce is a unique number that can be used only once in a SOAP request and is used to prevent replay attacks.
The nonce is cached to prevent its reuse. However, in a cluster environment you must take steps to synchronize this cache across the Managed Servers. Otherwise, a request sent to a Web service running on one server can be replayed and sent to another Managed Server, where it will be processed. Oracle WSM uses an instance of Java Object Cache (JOC) to cache the nonce.
You use the ORACLE_HOME/bin/configure-joc.py Python script to configure the JOC on all of the Managed Servers in distributed mode. The script runs in WLST online mode and expects the Administration Server to be up and running.
Note:
After configuring the Java Object Cache, restart all affected Managed Servers for the configurations to take effect.To enable the JOC in distributed mode, perform the following steps:
Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST), for example:
ORACLE_HOME/oracle_common/common/bin/wlst.sh $ connect()
Enter the Oracle WebLogic Administration user name and password when prompted.
After connecting to the Administration Server using WLST, start the script using the execfile command, for example:
wls:/mydomain/serverConfig>execfile('ORACLE_HOME/bin/configure-joc.py')
Configure JOC for all the Managed Servers for a given cluster.
Enter 'y' when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the Managed Servers for the given cluster and configures the JOC for each Managed Server. The discover port is common for the entire JOC configuration across the cluster. For example:
Do you want to specify a cluster name (y/n) <y> Enter Cluster Name : Spaces_Cluster Enter Discover Port : 9988
Here is a walkthrough for using configure-joc.py for HA environments:
execfile('ORACLE_HOME/bin/configure-joc.py') . Enter Hostnames (eg host1,host2) : SOAHOST1, SOAHOST2 . Do you want to specify a cluster name (y/n) <y>y . Enter Cluster Name : Spaces_Cluster . Enter Discover Port : 9988 . Enter Distribute Mode (true|false) <true> : true . Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
The script can also be used to perform the following JOC configurations:
Configure JOC for all specified Managed Servers.
Enter 'n' when the script prompts whether you want to specify a cluster name, and also specify the Managed Server and discover port, when prompted. For example:
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (eg WLS_Spaces1:9988, WLS_Spaces2:9988) : WLS_Spaces1:9988,WLS_Spaces2:9988
Exclude JOC configuration for some Managed Servers.
The script allows you to specify the list of Managed Servers for which the JOC configuration "DistributeMode" will be set to 'false'. Enter 'y' when the script prompts whether you want to exclude any servers from JOC configuration, and enter the Managed Server names to be excluded, when prompted. For example:
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WLS_Spaces1,WLS_Spaces3
Disable the distribution mode for all Managed Servers.
The script allows you to disable the distribution to all the Managed Servers for a specified cluster. Specify 'false' when the script prompts for the distribution mode. By default, the distribution mode is set to 'true'.
Verify JOC configuration using the CacheWatcher utility. For more information, see "Running CacheWatcher" in Oracle Fusion Middleware High Availability Guide.
You can configure the Java Object Cache (JOC) using the HA Power Tools tab in the Oracle WebLogic Administration Console as described in "Using HA Power Tools" in the Oracle Fusion Middleware High Availability Guide.
The Oracle WSM Agent run time uses the OracleSystemUser account by default to communicate to the server.
To configure a different default user, perform the following steps:
Configure an Authentication Provider
To configure an authentication provider, perform the following steps:
Configure an authentication provider, as described in "Configure Authentication and Identity Assertion providers" in Oracle WebLogic Server Administration Console Help.
Select the name of the realm you are configuring (for example, myrealm).
In the Create a New Authentication Provider page, enter the name for Authentication Provider (for example, OID) and select the type Oracle Internet Directory Authenticator.
In the Settings section, set Control Flag to OPTIONAL.
In the Provider Specific tab, enter the following:
Host: the LDAP provider URL
Port: port number
Principal: administrator user details (the new default user)
For example, CN=orcladmin,CN=Users,DC=us,DC=oracle,DC=com
Credential: password for LDAP
Confirm Credential: password for LDAP
User Base DN
For example, CN=Users,DC=us,DC=oracle,DC=com
Group Base DN
For example, CN=Groups,DC=us,DC=oracle,DC=com
Restart WebLogic Server.
Configure the Credential Store Provider
Configure the credential store provider as described in "Adding Keys and User Credentials to the Credential Store" with the following parameters:
If a map does not already exist, select Create Map and enter the map name oracle.wsm.security
.
In the Credential Store Provider table, select oracle.wsm.security
.
In the Create Key dialog, enter the appropriate key; for example, OID
. Enter the user name and password of the new default user (in this example, orcladmin
and welcome1
).
Configure the Platform Policy Configuration
To configure the Platform Policy, perform the following steps:
Log into Fusion Middleware Control with the new default user account.
In the navigator pane, expand WebLogic Domain to view the domains.
Select the domain for which you want to manage properties.
Select WebLogic Domain > Web Services > Platform Policy Configuration.
The Platform Policy Configuration page appears.
Select the Policy Accessor tab.
Click Add in the Policy Access Properties section.
In the Add New Configure Property dialog, enter the following:
Enter the name jndi.lookup.csf.key. This property provides credential configuration (java.naming.security.principal and java.naming.security.credentials) and is used when an account in the LDAP directory is configured to connect with the Oracle WSM Policy Manager.
Enter the value (in this example, OID).
Note:
The csf-key that you specify in this step must match the csf-key specified for the Policy Manager administrative user in the credential store. For more information, see "Configure the Credential Store Provider".Click OK.
Click Apply and restart WebLogic Server.
Modify the User's Group or Role
Oracle WSM Policy Manager uses the logical role (policy.Accessor) to secure EJBs that are accessed by the Oracle WSM Agent runtime to access the policies. By default, the policy.Accessor role is mapped to the groups OracleSystemGroup and Administrators. Oracle WSM Agent run time uses the OracleSystemUser identity to access wsm-pm. The new default user must either be included in the Administrator or OracleSystemGroup (if the groups exist), or be mapped to the logical role policy.Accessor (if the Administrator or OracleSystemGroup groups do not exist).
To ensure the user has the required role, perform the following steps:
If the Administrator or OracleSystemGroup groups exist in the LDAP or identity store, perform the following:
In LDAP, add the user that you would like to use as a default administrative user.
In WebLogic Server Administration Console, ensure that the user exists in the Administrator group. For more information, see "Manage Users and Groups" in Oracle WebLogic Server Administration Console Help.
If the Administrator or OracleSystemGroup groups do not exist in the LDAP or identity store, map the new user to the required logical role and redeploy the wsm-pm application using the modified deployment plan. To map the new user or existing users (belonging to a group other than Administrator or OracleSystemGroup), perform the following steps:
Create a deployment plan for deploying wsm_pm.ear. Example 14-4 describes a sample deployment plan. A sample deployment plan, shipped with WebLogic, is available in the ORACLE_HOME/modules/oracle.wsm.pm_11.1.1/prov folder. Modify the section @to_be_replaced@
with the new user.
Example 14-4 Sample Deployment Plan
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan
http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
<application-name>oracle.wsm.pm_11.1.1</application-name>
<variable-definition>
<variable>
<name>SecurityRoleAssignment_ejbRole_PrincipalName</name>
<value>@to_be_replaced@</value>
</variable>
</variable-definition>
<module-override>
<module-name>wsm-pmserver-wls.jar</module-name>
<module-type>ejb</module-type>
<module-descriptor external="false">
<root-element>weblogic-ejb-jar</root-element>
<uri>META-INF/weblogic-ejb-jar.xml</uri>
<variable-assignment>
<name>SecurityRoleAssignment_ejbRole_PrincipalName</name>
<xpath>/weblogic-ejb-jar/security-role-assignment/[role-name="policy.Accessor"]
/principal-name</xpath>
<operation>replace</operation>
</variable-assignment>
</module-descriptor>
</module-override>
</deployment-plan>
Redeploy the EAR.
For more information, see "Deploying an Application with a Deployment Plan" in Deploying Applications to Oracle WebLogic Server.
By default, the JMS System User is set as the OracleSystemUser. For most users, this default value is sufficient. However, if you must change this value to a custom user in your security realm, you can do so by changing the value of the user in Oracle Enterprise Manager Fusion Middleware Control and in the WebLogic Server Administration Console as described in the following procedure.
To change the JMS System User:
Access the Configuration tab on the Web Service Endpoint page for the asynchronous Web service as described in "Configuring Asynchronous Web Services".
Enter the name of the custom user in the JMS System User field and click Apply. See Figure 14-16.
Note:
The custom user must exist in the security realm and have the permissions required to access the JMS resources.Figure 14-16 Setting the JMS System User for Asynchronous Web Services
Access the WebLogic Server Administration Console. To do so from Fusion Middleware Control, select the domain in the navigator pane. From the WebLogic Domain menu, select WebLogic Server Administration Console.
Log into the WebLogic Server Administration Console using a valid username and password with the required administrative privileges.
Click Deployments in the Domain Structure pane and navigate to the corresponding service
_AsynchRequestProcessorMDB
or service
_AsynchResponseProcessorMDB
MDBs. In these MDB names, service
is the name of the asynchronous service for which you are changing the user name.
In the Change Center, select Lock & Edit.
Select the MDB name for the request or response MDB. (You must update the user name for both the request and response MDBs.) In the Settings page, select the Configuration tab.
In the Enterprise Bean Configuration section of the page, enter the custom user name in the Run As Principal Name field and click Save. See Figure 14-17.
Note that the user name you enter in this field must match the user name you entered for the JMS System User in Fusion Middleware Control.
Figure 14-17 WebLogic Server Administration Console Update for JMS System User
The configuration changes must be saved in a new deployment plan.
Use the Save Deployment Plan Assistant to save the new deployment plan.
Repeat steps 7 and 8 for the second MDB. The changes are automatically saved to the new deployment plan.
In the Change Center, click Activate Changes.
Redeploy the application. For more information, see Chapter 5, "Deploying Web Services Applications."