13 Advanced Administration

This chapter includes the following sections:

Registering Web Services

You can register a Web service so that you can later more conveniently reference the service from a selection list without having to specify a URL for a WSDL. For example, when testing a Web service, you can click the Locate icon and then select the WSDL from the registered services, as shown in Figure 13-1.

Figure 13-1 Selecting From a Registered Service

Description of Figure 13-1 follows
Description of "Figure 13-1 Selecting From a Registered Service"

Fusion Middleware Control provides support for registering Web services that are published in WS-Inspection (WSIL) documents and UDDI v3 registries. Any service that is available in a WSIL document or a UDDI v3 registry can be registered.

When you register Web services, you do so by specifying any of the following:

  • URL to a WSIL document

  • File location of a WSIL document

  • UDDI v3 URL

WSIL Basics

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.

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.

Registering a Web Service

Follow the steps in this section to register a service.

To register a service

  1. In the navigator pane, expand WebLogic Domain to show the domain in which you want to register a Web service.

  2. Select the domain.

  3. Using Fusion Middleware Control, click WebLogic Domain and then Web Services and then Registered Services. The Registered Service page appears, as shown in Figure 13-2.

    Figure 13-2 Registering Services Page

    Description of Figure 13-2 follows
    Description of "Figure 13-2 Registering Services Page"

  4. Click Register to register a service. The Register New Service page appears, as shown in Figure 13-3.

    Figure 13-3 Registering New Service Page

    Description of Figure 13-3 follows
    Description of "Figure 13-3 Registering New Service Page"

  5. Select from WSIL import from URL, WSIL import from File, or UDDI v3 registry import.

  6. For WSIL import from URL, enter the WSIL URL. Enable Basic Authorization and provide a username and password if required to access the WSIL.

    For WSIL import from File, enter the file specification and click Browse.

    For UDDI v3 registry import, enter the UDDI inquiry URL. For example, http://somehost/uddi/inquiry.

  7. Click Process to parse your input.

  8. For UDDI v3 registry import, the services available in the UDDI are displayed. Select one or more services to register.

  9. Click Register to register the service or services.

  10. If the registration is successful, the page expands to show the registered services. You can click Edit to change the service name and description from this page, if desired.

  11. If the current WSIL also references other Web services, expand References Available in WSIL to display them. You can register the referenced Web services as well.

Viewing and Editing a Registered Web Service

Follow the steps in this section to view and edit a registered Web service.

  1. In the navigator pane, expand WebLogic Domain to show the domain in which you want to view the registered Web services.

  2. Select the domain.

  3. Using Fusion Middleware Control, click WebLogic Domain and then Web Services and then Registered Services. The Registered Service page appears, as shown in Figure 13-2.

  4. The registered Web services are displayed. Select the Web service and click Edit to edit the registered service.

Unregistering a Web Service

Follow the steps in this section to unregister a Web service.

  1. In the navigator pane, expand WebLogic Domain to show the domain in which you want to unregister a Web service.

  2. Select the domain.

  3. Using Fusion Middleware Control, click WebLogic Domain and then Web Services and then Registered Services. The Registered Service page appears, as shown in Figure 13-2.

  4. The registered Web services are displayed. Select the Web service you want to unregister and click Unregister.

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 runtime. 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 runtime. 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 Settings page. You can audit SOA, ADF, and WebCenter services.

Figure 13-4 Audit Policy Settings Page

Description of Figure 13-4 follows
Description of "Figure 13-4 Audit Policy Settings Page"

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 13-1 Auditing Events for Web Services

Enable auditing for the following Web service events . . . Using this system component . . .
  • User authentication.

  • User authorization.

  • Policy enforcement, including message integrity, message confidentiality, and security policy.

Oracle Web Services Manager—Agent

  • Web service requests sent and responses received.

  • SOAP faults incurred.

Oracle Web Services

  • Oracle WSM policy creation, deletion, or modification.

  • Assertion template creation, deletion, or modification.

Oracle Web Services Manager

  • Oracle WSM policy attachment.

Oracle Web Services Manager— Policy Attachment


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

The following sections describe how to define audit policies and view audit data:

Configuring Audit Policies

To configure audit policies:

  1. In the Navigator pane, expand WebLogic Domain.

  2. Click the domain for which you want to manage assertion templates.

  3. From the WebLogic Domain menu select Security > Audit Policy Settings.

    The Audit Policy Settings page is displayed.

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

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

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

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

  • Set up audit event collection.

For more information, see "Managing Audit Data Collection and Storage" in Oracle Fusion Middleware Security Guide.

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.

To manage the WSDL:

  1. Navigate to the Web Service endpoint configuration page, as described in "Configuring the Web Service Port".

  2. On the Configuration tab, set the WSDL Enabled field to True or False to enable of disable public access to your WSDL, respectively.

  3. Click Apply.

Managing Policy Assertion Templates

The following sections describe how to create and manage policy assertion templates.

Navigating to the Web Services Assertion Templates Page

You can manage your assertion templates at the domain level from the Web Services Assertion Template page. From this page, you can copy, edit, and delete assertion templates.

To navigate to the Web Services Assertion Templates page:

  1. In the Navigator pane, expand WebLogic Domain.

  2. Click the domain for which you want to manage assertion templates.

  3. From the WebLogic Domain menu select Web Services > Policies.

    The Web Services Policies page is displayed.

  4. Click Web Services Assertion Templates in the upper right corner of the page.

    The Web Services Assertion Templates page is displayed, as shown in the following figure.

Figure 13-5 Web Services Assertion Templates Page

Description of Figure 13-5 follows
Description of "Figure 13-5 Web Services Assertion Templates Page"

Viewing an Assertion Template

To view an assertion template:

  1. Navigate to the Web Services Assertion Templates page, as described in "Navigating to the Web Services Assertion Templates Page".

  2. Select the assertion template from the Assertion Templates table that you want to view.

  3. Click View.

  4. In the View Template page, review the assertion.

  5. When you are done, click Return to Web Services Assertion Templates.

Searching for an Assertion Template

You can search for a Web service assertion template by category, name, or both.

To search for an asserting template:

  1. Navigate to the Web Services Assertion Templates page, as described in "Navigating to the Web Services Assertion Templates Page".

  2. Perform one or more of the following steps:

    • To search for assertion templates in a specific category (or all categories), select a category from the Category dropdown list.

      Valid categories include: All, Security, MTOM Attachments, Reliable Messaging, WS-Addressing, and Management.

    • To search for an assertion template that contains a specific string, enter a string in the Name field.

      Specify any portion of the name of an assertion template to display all assertion templates that contain the string for the specified category.

  3. Click Go.

    The assertion templates list is refreshed to include only those assertion templates that match the specified search criteria.

Creating an Assertion Template

A new assertion template is created based on an existing assertion. Pick the assertion template that most closely matches the desired behavior, then make any changes required to get the desired behavior.

To create an assertion template:

  1. Navigate to the Web Services Assertion Templates page, as described in "Navigating to the Web Services Assertion Templates Page".

  2. Select the assertion template from the Assertion Templates table that you want to copy.

  3. Click Create Like.

    The following shows the Create Template page.

    Figure 13-6 Create Template Page

    Description of Figure 13-6 follows
    Description of "Figure 13-6 Create Template Page"

  4. In the Copy Assertion Template box, edit the name of the assertion and enter a brief description.

    The word Copy is appended to the name of the copied assertion template and, by default, this is the name assigned to the new assertion template. For example, if the assertion template being copied is named oracle/wss10_username_token_service_template, then the default name of the copy is oracle/wss10_username_token_service_template_Copy.

    It is recommended that you change the name of this new assertion template to be more meaningful in your environment.

  5. Click OK.

    The assertion is added to the Assertion Templates table. You can now select the new assertion and click Edit to configure the assertion.

Exporting an Assertion Template

You can export individual assertion templates from Oracle Enterprise Manager Fusion Middleware Control. You can then copy the assertion template to a directory or import the assertion template to move it to another repository. Once moved, you can import the assertion template, as described in "Importing an Assertion Template".

To export an assertion template:

  1. Navigate to the Web Services Assertions Templates page, as described in "Navigating to the Web Services Assertion Templates Page".

  2. Select the assertion template from the Assertion Templates table that you want to export to a file.

  3. Click Export to File.

    You are prompted to open or save the file.

  4. Select Save File.

  5. Click Ok.

  6. Navigate to the location on your local directory to which you want to save the file and update the filename as desired.

  7. Click Save.

Importing an Assertion Template

To import an assertion template:

  1. Navigate to the Web Services Assertions Templates page, as described in "Navigating to the Web Services Assertion Templates Page".

  2. Click Import From File.

    You are prompted to provide the assertion template file.

  3. Click Browse to navigate to the directory where the assertion template file is located and select the assertion template to be imported.

  4. Click OK.

    The assertion template appears in the Assertion Templates table.

Editing an Assertion Template

To edit an assertion template:

  1. Navigate to the Web Services Assertions Templates page, as described in "Navigating to the Web Services Assertion Templates Page".

  2. Select the assertion template from the Assertion Templates table that you want to edit.

  3. Click Edit.

  4. Edit the assertion template as required.

  5. Click Save.

Deleting an Assertion Template

To delete an assertion template:

  1. Navigate to the Web Services Assertions Templates page, as described in "Navigating to the Web Services Assertion Templates Page".

  2. Select the assertion template from the Assertion Templates table that you want to delete.

  3. Click Delete.

    You are prompted to confirm that you want to delete the assertion template.

  4. Click OK.

About the Metadata Services (MDS) Repository

When you install Oracle Fusion Middleware, you have the option of using a database-based MDS repository.

For a list of the databases that are supported for this release, see Oracle Fusion Middleware Supported System Configurations at: http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

To register a MDS repository, expand Metadata Repositories in the Navigator pane, as shown in Figure 13-7.

Figure 13-7 Metadata Repository in Navigation Pane

Description of Figure 13-7 follows
Description of "Figure 13-7 Metadata Repository in Navigation Pane"

Then, register a metadata repository, as shown in Figure 13-8.

Figure 13-8 Registering a Metadata Repository

Description of Figure 13-8 follows
Description of "Figure 13-8 Registering a Metadata Repository"

See "Managing the Oracle Metadata Repository" in the Oracle Fusion Middleware Administrator's Guide for information on managing the metadata repository.

Upgrading the Oracle WSM Policies in the MDS Repository

In Oracle WSM 11g, predefined and custom Oracle WSM policies are stored in the Oracle MDS repository. In subsequent releases, these predefined policies may be discontinued, changed, or additional predefined policies may be provided. You can use Oracle WebLogic Scripting Tool (WLST) commands to upgrade the repository with new or updated predefined policies when you install a new version of the Fusion Middleware software. You can also refresh the repository by deleting all Oracle WSM policies from the repository, including custom policies, and then repopulating it using the predefined policies provided in your installation. All of the policies in the repository are also revalidated when you upgrade the repository.

To upgrade the MDS repository:

  1. Install the new version of Oracle Fusion Middleware.

  2. Ensure that the MDS repository to be upgraded is registered with the new installation of Oracle Fusion Middleware. For more information, see "About the Metadata Services (MDS) Repository".

  3. Invoke WLST from the Oracle home in which you installed the new version of Oracle Fusion Middleware as described in "Accessing the Web Services Custom WLST Commands".

  4. Do one of the following:

    • To add new predefined policies that are provided in the latest installation of the Oracle Fusion Middleware software, enter the following command:

      upgradeWSMPolicyRepository()

      When you execute this command, a message is displayed indicating the policies that have been added to the repository. Note that existing predefined and user-defined custom policies in the repository are unchanged. The output message also displays a list of any existing predefined policies that have changed or discontinued in the latest release. If a policy has been discontinued and is no longer supported, Oracle recommends that you remove all references to it and then delete it using Oracle Enterprise Manager. If a predefined policy has changed in the latest release, Oracle recommends that you import the updated version of the policy using Oracle Enterprise Manager. For details about deleting and importing policies using Enterprise Manager, see Chapter 7, "Managing Web Service Policies."

    • To delete existing predefined policies stored in the repository and replace them with the latest set of predefined policies, use the following command:

      resetWSMPolicyRepository(false)

      User-defined custom policies are unchanged. An output message is displayed that lists the predefined policies that have been added, deleted, or replaced in the repository.

    • To delete all policies from the repository, including custom policies, and replace them with the latest set of predefined policies, use the following command:

      resetWSMPolicyRepository(true)

      Before you delete a policy, Oracle recommends that you verify that the policy is not attached to any policy subjects.

    When you execute any of these commands, all existing policies are revalidated.

    For more information about these WLST commands, see "Policy Repository Upgrade Commands" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

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 in order 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.

Managing Policy Accessor, Cache, and Interceptor Properties

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

  • Policy Accessor

  • Policy Cache

  • Policy Interceptors

  • Identity Extension

To manage policy accessor, cache, interceptor, and identity extension properties:

  1. In the navigator pane, expand WebLogic Domain to view the domains.

  2. Select the domain for which you want to manage properties.

  3. Select WebLogic Domain> Web Services > Platform Policy Configuration.

    The Platform Policy Configuration page appears, as shown in Figure 13-9.

    Figure 13-9 Platform Policy Configuration Page

    Description of Figure 13-9 follows
    Description of "Figure 13-9 Platform Policy Configuration Page"

  4. Select the tab corresponding to the component for which you want to define properties: Policy Accessor, Policy Cache, Policy Interceptors, or Identity Extension.

  5. If you selected the Policy Interceptors tab, select the interceptor for which you want to add properties in the list.

  6. Perform one of the following tasks:

    • Click Add to define a new property.

      Enter the name of the property and value and click OK.

    • Select a property and click Edit to modify an existing property.

    • Select a property and click Delete to delete an existing property.

  7. Click Apply to apply the property updates.

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:

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

  2. 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')
    
  3. 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 configure the JOC f 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. See 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 the Oracle Fusion Middleware High Availability Guide.

Deleting the OracleSystemUser Default User

If you delete OracleSystemUser default user in favor of using the csf-key, then you must perform the following steps:

  1. Add the following property and value to the Policy Accessor configuration. For more information, see "Managing Policy Accessor, Cache, and Interceptor Properties".

    Name: jndi.lookup.csf.key

    Value: basic.credentials

  2. Ensure that the jndi.lookup.csf.key property is defined in the credential store. For example, basic.credential should be present in the credential store. For more information, see "Configuring the Credential Store Provider".

  3. Restart the server.