It includes the following topics:
OWSM is installed by default when you install Oracle Fusion Middleware Infrastructure. However, if you have a standalone WebLogic Server environment with JAX-WS web services and clients deployed, you can install OWSM and use it to secure your web services and clients.
OWSM is licensed only through SOA Suite; a standalone license is not available. For information about licensing, see Licensing Considerations for Additional Features.
To use OWSM with WebLogic Server, you need Java Required Files (JRF) and Oracle Enterprise Manager Fusion Middleware Control. JRF consists of those components that provide common functionality for Oracle business applications and application frameworks. Oracle Enterprise Manager Fusion Middleware Control can be used to secure and administer Java EE (WebLogic) web services.
The Oracle Fusion Middleware Infrastructure standard installation topology includes OWSM, JRF and Enterprise Manager. Information about this topology and detailed installation procedures are provided in Installing the Infrastructure Software. To use OWSM with WebLogic Server, follow the procedures in that document to install and configure the Oracle Fusion Middleware Infrastructure standard installation topology.
After you complete the installation and configure the domain, you can secure your Java EE (WebLogic) JAX-WS web services using OWSM as described in this document. You cannot attach OWSM policies to JAX-RPC web services.
Procedures for administering Java EE (WebLogic) web services are provided in Administering Web Services.
When your domain is configured to use an administration port, all tasks performed by administrators must go through this port. By default, the OWSM 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 Administering Server Environments for Oracle WebLogic Server.
"Configure the domain-wide administration port" in Oracle WebLogic Server Administration Console Online Help.
Configuring OWSM with a domain-wide administration port requires two main steps:
The Policy Manager application is targeted to the Administration Server to configure OWSM. You can use 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 in Administering Web Services with Oracle Fusion Middleware.
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 Administering Web Services with Oracle Fusion Middleware.
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.
The policy accessor URL is specified for the Policy Manager on the Administration Server to configure OWSM. You can use Fusion Middleware Control to specify the policy accessor URL for the Policy Manager on the administration server.
To specify the policy accessor URL for the Policy Manager on the administration server:
When an override port is configured for the Administration Server, use:
This specifies the location of a running Policy Manager running on the Administration Server.
Note: When using an override port, the Policy Manager Validator page will still be located at
/wsm-pm, and not on the override port. For more information, see "Diagnosing Policy Manager Problems Using the OWSM Policy Manager Page".
Cross-component wiring provides a simplified method for wiring Fusion Middleware components. It automates the wiring process and provides the ability to diagnose wirings after they are established.
Wiring is simply a piece of configuration in one component that points to another component, such as a URL that points to the admin interface of a component. With cross-component wiring:
Service providers publish their endpoints to a Service Table. These endpoints can be published automatically, such as when you create or extend a domain using the Configuration Wizard, or can be published manually by the administrator.
Clients contain configuration that points to the service (for example, it has the service URL). The client is "bound" to the service by updating this configuration with the service information that was published to the Service Table. Binding is performed automatically when creating or extending a domain using the Configuration Wizard, or can be done manually by the administrator.
When you install and configure Fusion Middleware on WebLogic Server, the local service table is created. It provides a means for service providers to publish endpoint information about their services, and for clients of these services to query and bind to these services. The Local Service table is scoped to a domain, and contains services that are offered by that domain. For detailed information about service tables and cross-component wiring, see "Cross-Component Wiring" in Administering Oracle Fusion Middleware.
OWSM uses cross-component wiring to auto-discover the Policy Manager in the domain. When you use the Configuration Wizard to create or update a domain that includes OWSM, Policy Manager URLs are published to the Local Service table. The OWSM Agent is automatically wired to the OWSM Policy Manager using the endpoint entries published to the Local Service table.
If, however, you change the domain using tools other than the Configuration Wizard (such as the WebLogic Administration Console, Fusion Middleware Control, or WLST), any changes to the Policy Manager URL are automatically published to the Local Service table but the OWSM Agent client is not automatically bound to the new URL. In this case, you need to manually bind the OWSM Agent to the Policy Manager URL. For more information, see "Verifying Agent Bindings Using Fusion Middleware Control".
You can change and disable the auto-discovery settings as described in the following sections:
Use Fusion Middleware Control to verify service table entries and agent bindings.
This topic describes how to verify service table entries and agent bindings using Fusion Middleware Control:
You can use the Service Tables page and the Components page in the Fusion Middleware Control to verify the service table entries and components.
To verify that the service table entry contains the correct URL for the Policy Manager:
Using the Service Tables page
From the WebLogic Domain menu, select Cross Component Wiring, then Service Tables.
In the Service Table, verify that the URL in the Connection column and the Last Published date reflect the correct information for the OWSM Policy Manager with the Service ID
If you are using a static or dynamic cluster, then select the Service ID and click Edit and update the t3 and t3s values with the cluster name syntax.
The cluster name syntax is as follows:
When you use
cluster:t3s://<cluster_name>, the CCW invocation fetches the complete list of members in the cluster at any given time, thus avoiding any dependencies on the initial servers and accounting for every member that is alive in the cluster then.
Using the Components page
From the WebLogic Domain menu, select Cross Component Wiring, then Components.
In the Component Type table, select OWSM Policy Manager.
In the Service End Points table, verify that the correct URL is shown in the Connection column and that the status is
Published for the OWSM Policy Manager with Service ID
urn:oracle:fmw.owsm-pm:t3. If the status is not
Published (for example
Out of Sync), you can also use this page to publish the Policy Manager connection. To do so, select the Policy Manager in the table and click Publish.
You can use the Fusion Middleware Control to verify that the OWSM Agent is wired correctly.
To verify that the OWSM Agent is wired correctly to the appropriate Policy Manager URL:
From the WebLogic Domain menu, select Cross Component Wiring, then Components.
In the Components Table, select OWSM Agent.
In the Client Configurations table, verify that the Client ID
owsm-pm-connection-t3 reflects the correct Policy Manager URL in the Connection column, and shows the status as
Wired in the Status column.
If the Status column displays
Out of Sync, you need to bind the Agent to the Policy Manager. To do so:
owsm-pm-connection-t3 in the Client Configurations table and click Bind.
In the Bind Client Configuration page, verify that the Service End Point contains the correct Policy Manager URL and click Yes.
Confirmation is displayed on the Components page and the status of the Agent is changed to
The OWSM Agent run time uses the OracleSystemUser account and OracleSystemGroup, by default, to communicate to the server.
To modify the default user, perform the steps described in the following sections:
This topic describes how to configure the authentication provider using Oracle WebLogic Server Administration Console.
To configure an authentication provider:
Select the name of the realm you are configuring (for example,
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
This topic describes how to configure the credential store provider.
Configure the credential store provider as described in "Adding Keys and User Credentials to Configure the Credential Store" with the following parameters:
If a map does not already exist, select Create Map and enter the map name
In the Credential Store Provider table, select
In the Create Key dialog, enter the appropriate key; for example,
OID. Enter the user name and password of the new default user (for example,
This topic describes how to configure the Policy Manager CSF key using Fusion Middleware Control.
To configure the Policy Manager CSF key for the domain:
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 "Configuring the Credential Store Provider".
Using the example provided in that section, select the OID key from the PM Csf Key drop-down menu, and enter
password as the credential/password combination.
The OWSM Agent runtime uses the
OracleSystemUser identity to access
wsm-pm. If you define a new default user, it must be included in either the Administrator or
OracleSystemGroup group (if the groups exist), or be mapped to the default OWSM logical roles
Map the new default user to the default OWSM logical roles defined in Table 2-1 (if the groups do not exist).
Table 2-1 Default OWSM Logical Roles
Create, edit, delete, and update policies.
All authenticated users
Read-only permission (for example, query/view document information).
Used by the OWSM Policy Manager to secure EJBs that are accessed by the OWSM Agent runtime to attach policies.
The OWSM Agent run time uses the OracleSystemUser account and OracleSystemGroup, by default, to communicate to the server. After the default user is modified each User is assigned a required role.
To ensure that the user has the required role:
If the Administrator or OracleSystemGroup groups exist in the LDAP or identity store, perform the following steps:
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 Online Help.
If the Administrator or OracleSystemGroup groups do not exist in the LDAP or identity store, you can manage application roles using one of the following OPSS scripts:
grantAppRole—Adds a principal (class and name) to a role with a given application stripe and name.
revokeAppRole—Removes a principal (class and name) to a role with a given application stripe and name.
listAppRoleMembers—Lists all members in a role with a given application stripe and role name.
For more information about these and other OPSS scripts, see "Managing the Policy Store" in Securing Applications with Oracle Platform Security Services.
The following examples illustrate how to use the OPSS scripts.
Before issuing the OPSS scripts, you must start WLST and connect to the running instance of WebLogic Server, as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.
The following command adds the
policy.Accessor role to a principal named
grantAppRole(appStripe="wsm-pm", appRoleName="policy.Accessor",principalClass="weblogic.security.principal.WLSUserImpl", principalName="PAPUser")
The following command removes the
policy.Accessor role from
revokeAppRole(appStripe="wsm-pm", appRoleName="policy.Accessor",principalClass="weblogic.security.principal.WLSGroupImpl", principalName="OracleSystemGroup")
The following command lists the members associated with the