Registering Web Services and Sources

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.

UDDI Basics

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 Basics

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.

Viewing Registered Sources and Web Services

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.

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.

Registering a Source

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.

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.

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.

Registering Web Services from a WSIL Source

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.

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.

Deleting a Web Service or Web Service Source

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.

Publishing Web Services to UDDI

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. The following procedures describe both methods.

Note:

You need to 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".

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.

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.

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.

Auditing Web Services

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.

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.

Managing Audit Data Collection and Storage

To manage the data collection and storage of audit information, you need to 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.

Viewing Audit Reports

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 Security Guide.

For file-based repositories, you can view the bus-stop files using a text editor and create your own custom queries.

Managing the WSDL

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 will need to have a local copy of the WSDL.

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.

Adding Security to a Running Client

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.

Configuring Platform Policy Properties

You can manage properties for the following components from the Platform Policy Configuration page:

Configuring a Web Service on a Remote Policy Manager and Tuning the Policy Cache

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 want to access an Oracle WSM Policy Manager that is running in a different domain (without additional WebLogic security configuration).

You are running on a non-WebLogic application server that does not support the auto-discovery feature, such as WebSphere Application Server and JBOSS.

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 explicitly set a remote JNDI provider URL and corresponding csf-key credentials to access a Policy Manager in a remote domain or on another platform.

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 a remote Oracle WSM Policy Manager.

To configure a Web service on a remote Oracle WSM Policy Manager and tune the policy cache:

To access an Oracle WSM Policy Manager that is in a different domain—for example, if the Oracle WSM Policy Manager is in a domain that is different from the Web service client—enable cross-domain security between WebLogic Server domains, as described in "Enabling Cross Domain Security Between WebLogic Server Domains" in Securing Oracle WebLogic Server.

Cross domain security establishes trust between two WebLogic domain pairs by using a credential mapper to configure communication between these WebLogic domains.

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 remote domain.

This specifies the location of a running Policy Manager in a different domain in order to access that Policy Manager. If this property is not specified, the auto-discovery feature attempts to look up the Policy Manager in the same domain.

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.

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 (if any) 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 "Configuring Web Service Policy Retrieval".

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.

Configuring Web Service Policy Retrieval

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 accessor type (for example, classpath, local, or remote), repository location (JARs, directory, or host and port), account information (for a remote repository), retry logic (for high availability), and cache tuning.

Use the following table to specify the available property names and values in the Add 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 in another domain. By default, this property is not specified. If this property is not specified, Oracle WSM auto-discovery attempts to look up the Policy Manager in the same domain.

jndi.lookup.csf.key

If the location of the Oracle WSM Policy Manager is provided in the java.naming.provider.url property, the jndi.lookup.csf.key provides credential configuration. Because the Oracle WSM Policy Manager is security enabled, the jndi.lookup.csf.key specifies the java.naming.security.principal and java.naming.security.credentials when using the JNDI URL to look up a Oracle WSM Policy Manager. By default, this property is not specified.

You should configure this property when:

You want to specify an explicit account to connect with the Oracle WSM Policy Manager rather than the system account, OracleSystemUser, that is used by Oracle WSM by default.

The Authentication Provider and LDAP directory that is configured does not support system accounts used by Oracle WebLogic, but which Oracle WSM 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.

cache.refresh.initial

Number of milliseconds to wait before initial cache refresh. The default is 600000 milliseconds (10 minutes).

cache.refresh.repeat

Number of milliseconds to wait between cache refreshes. The default is 600000 milliseconds (10 minutes).

missing.entry.delay

Number of milliseconds to wait before trying to retrieve a missing document. The default is 15000 milliseconds.

usage record.delay

Number of milliseconds to wait before sending usage data. The default is 30000 milliseconds.

failure.retry.count

Number of times to retry after communication failure. The default is 2 retry attempts.

failure.retry.delay

Number of milliseconds to wait between retry attempts. The default is 5000 milliseconds.

oracle.wsm.policymanager.accessor.IRepositoryAccessor

Type of repository accessor class. The values are:

remote (Java EE)

classpath (default for Java SE)

local (Java SE)

access.protocol

Alias for the oracle.wsm.policymanager.accessor.IRepositoryAccessor property. The values are:

remote (Java EE)

classpath (default for Java SE)

local (Java SE)

wsm.repository.path

Defines the location of the JAR file(s) or local file-based repository from which to load documents, depending on the value of the oracle.wsm.policymanager.accessor.IRepositoryAccessor property:

repository accessor type=classpath – Specify the location of the JAR file from which to load documents. Multiple JARs must be separated by the ":" path separator. A JAR can also include leading directories. For example, you could define /library/policies.jar to only accept JARs in a directory named library. This allows the administrator to prevent picking up like-named JARs that may not have the desired content.

repository accessor type=remote – This property has no meaning when using the remote (Java EE) accessor.

mds.module.home

Alias for the wsm.repository.path property.

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.

Tuning Web Service Security Policy Enforcement

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.

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.

agent.clock.skew – 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. The default value is 300 seconds.

agent.nonce.ttl – 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. The default value is 28800 seconds.

agent.expire.time – 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. The default value is 300 seconds.

Click OK.

To delete an existing property, select it and then click Delete.

Click Apply to apply the property updates.

Defining Identity Extension Properties

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 is published, you can also specify whether to ignore the hostname verification feature.

Defining a Trusted Distinguished Name List for SAML Signing Certificates

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.

Imporant Notes:

Using the Trusted SAML clients and Trusted STS servers tabs, 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 need to be present in the trusted DNs list.

In all cases, the signing certificates must be trusted by the certificates present in the OWSM keystore.

Setting Up the Java Object Cache

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.

Running the configure-joc.py Script

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:

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

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:

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'.

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.

Changing the OracleSystemUser Default User

By default, the Oracle WSM Policy Manager uses the OracleSystemUser account to communicate with the server. To configure a new default user, perform the following steps:

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.

In LDAP, create a group with the name Administrators.

Add the user that you would like to use as a default administrative user.

Verify that you can log in to Administration Console with the user account added to Administrators group.

Select Providers > Authentication and click the name of the new Authentication provider (in this example, OID).

In the Settings section, set Control Flag to REQUIRED.

Re-order the authentication providers and move the new Authentication provider (in this example, OID) to the top of the order. For more information, see "Re-order security providers" in Oracle WebLogic Server Administration Console Help.

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.

Changing the JMS System User for Asynchronous Web Services

By default, the JMS System User is set as the OracleSystemUser. For most users, this default value is sufficient. However, if you need to 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.

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 will need to 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-13.

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.