8 Advanced User Tools

Web Services Policy-Based Security

OracleAS Adapter Application Explorer (Application Explorer) provides a security model called Web services policy-based security. This section describes how the feature works and how to configure it.

Web services provide a layer of abstraction between the back-end business logic and the user or application running the Web service. This enables easy application integration but raises the issue of controlling the use and execution of critical and sensitive business logic that is run as a Web service.

Application Explorer controls the use of Web services that use adapters, using a feature called policy-based security. This feature enables an administrator to apply "policies" to Business Services (Web services) to deny or permit their execution.

A policy is a set of privileges dealing with the execution of a Business Service (BS) that can be applied to an existing or new BS. When you set specific rights or privileges inside a policy, you do not have to re-create privileges for every BS that has security concerns in common with other Business Services. Instead, you reuse a policy on multiple Business Services.

The goal of the feature is to secure requests at both the transport and the SOAP request level transmitted on the wire. Some of the policies do not deal with security issues directly, but do effect the runtime behavior of the Web services to which they have been applied.

The Business Services administrator creates an "instance" of a policy type, names it, associates individual users or groups (a collection of users), and then applies that policy to one or more Business Services.

You can assign a policy to a Business Service, or to a method within a Business Service. If a policy is only applied to a method, other methods in that Business Service will not be governed by it. However, if a policy is applied to the Business Service, all methods are governed by it. At runtime, the user ID and password that are sent to OracleAS Adapter Business Services Engine (BSE) in the SOAP request message are verified against the list of users for all policies applied to that specific Business Service. The policy type that is supported is Resource Execution, which dictates who can or cannot execute the Business Service.

When a policy is not applied, the default value for a Business Service is to "grant all". For example, anybody can execute the Business Service, until the Resource Execution policy is associated to the Business Service. At that time, only those granted execution permissions, or users not part of the group that has been denied execution permissions, have access to the Business Service.

Configuring Web Services Policy-Based Security

The following procedures describe how to configure Web services policy-based security.

Creating and Associating a User with a Policy

Before you create instances of policies, you must have a minimum of one user or one group to associate to an instance. You can create users and groups using Application Explorer.

1. Start Application Explorer.

2. Right-click the configuration to which you want to connect, for example, SampleConfig. See Chapter 2, "Configuring OracleAS Adapter for J.D. Edwards One World" for information on creating a new configuration.

3. Select Connect.

   Nodes appear for Adapters, Events, and Business Services (also known as Web services).

   
   Description of the illustration new_config.gif
   
   

   Perform the following steps:

   1. Expand the Business Services node.

   2. Expand the Configuration node.

   3. Expand the Security node.

   4. Expand the Users and Groups node.

      
      Description of the illustration new_usr.gif
      
      

4. Right-click Users and click New User.

   The New User dialog box is displayed.

   
   Description of the illustration new_usr_dialog.gif
   
   

   Perform the following steps:

   1. In the Name field, enter a user ID.

   2. In the Password field, enter the password associated with the user ID.

   3. In the Description field, enter a description of the user (optional).

5. Click OK.

   
   Description of the illustration newuser.gif
   
   

The new user is added under the Users node.

Creating a Group to Use with a Policy

To create a group to use with a policy:

1. Start Application Explorer.

2. Right-click the configuration to which you want to connect, for example, SampleConfig. See Chapter 2, "Configuring OracleAS Adapter for J.D. Edwards One World" for information on creating a new configuration.

3. Select Connect.

   Nodes appear for Adapters, Events, and Business Services (also known as Web services).

   
   Description of the illustration new_config.gif
   
   

   Perform the following steps:

   1. Expand the Business Services node.

   2. Expand the Configuration node.

   3. Expand the Security node.

   4. Expand the Users and Groups node.

   
   Description of the illustration groups.gif
   
   

4. Right-click Groups and select New Group.

   The New Group dialog box is displayed.

   
   Description of the illustration addnewgrp.gif
   
   

   Perform the following steps:

   1. In the Name field, enter a name for the group.

   2. In the Description field, enter a description for the group (optional).

   3. From the available list of users in the left pane, select one or more users and add them to the Selected list by clicking the double right facing arrow.

5. When you have selected at least one user, click OK.

The new group is added under the Group node.

Creating an Execution Policy

An execution policy governs who can execute the Business Services to which the policy is applied.

To create an execution policy:

1. Start Application Explorer.

2. Right-click the configuration to which you want to connect, for example, SampleConfig. See Chapter 2, "Configuring OracleAS Adapter for J.D. Edwards One World" for information on creating a new configuration.

3. Select Connect.

   Nodes appear for Adapters, Events, and Business Services (also known as Web services).

   
   Description of the illustration new_config.gif
   
   

   Perform the following steps:

   1. Expand the Business Servicesnode.

   2. Expand the Configuration node.

   3. Expand the Security node.

   4. Expand the Policies node.

      
      Description of the illustration policies.gif
      
      

4. Right-click Policies and select New Policy.

   The New Policy dialog box is displayed.

   
   Description of the illustration addpolicy.gif
   
   

   Perform the following steps:

   1. In the Name field, enter a name for the policy.

   2. From the Type list, select Execution.

   3. In the Description field, enter a description for the policy (optional).

   4. From the available list of users in the left pane, select one or more users and add them to the Selected list by clicking the double right facing arrow.

      
      

      Note: This user ID is verified against the value in the user ID element of the SOAP header sent to BSE in a SOAP request.

      
      

5. When you have selected at least one user selected, click OK.

6. Click Next.

The New Policy permissions dialog box is displayed.

Description of the illustration permissions.gif

7. To grant permission to a user or group to execute a Business Service, select the user or group and move them into the Execution Granted list by selecting the double left facing arrow.

8. To deny permission to a user or group to execute a Business Service, select the user or group and move them into the Execution Denied list by selecting the double right facing arrow.

9. Click OK.

   The following pane summarizes your configuration.

Description of the illustration summary.gif

Using the IP and Domain Restrictions Policy Type

You configure the IP and Domain Restriction policy type slightly differently from other policy types. The IP and Domain Restriction policy type controls connection access to BSE and therefore need not be applied to individual Web services. You need not create a policy, however, you must enable the Security Policy option in Application Explorer.

1. Start Application Explorer.

2. Right-click the configuration to which you want to connect, for example, SampleConfig. See Chapter 2, "Configuring OracleAS Adapter for J.D. Edwards One World" for information on creating a new configuration.

3. Select Connect.

   Nodes appear for Adapters, Events, and Business Services (also known as Web services).

   Perform the following steps:

   1. Expand the Business Services node.

   2. Expand the Configuration node.

   3. Expand the Security node.

Description of the illustration domain.gif

4. Right-click IP and Domain and select New IP and Domain Restriction.

   The New IP and Domain Restriction dialog box is displayed.

   
   Description of the illustration add_dom.gif
   
   

   Perform the following steps:

   1. In the IP(Mask)/Domain field, enter the IP or domain name using the following guidelines.

      If you select Single (Computer) from the Type list, you must provide the IP address for that computer. If you only know the DNS name for the computer, click DNS Lookup to obtain the IP Address based on the DNS name.

      If you select Group (of Computers), you must provide the IP address and subnet mask for the computer group.

      If you select Domain, you must provide the domain name.

   2. From the Type list, select the type of restriction.

   3. In the Description field, enter a description (optional).

   4. To grant access, select the Grant Access check box.

5. Click OK.

The new domain is added under the IP and Domain node.

The following pane summarizes your configuration.

Description of the illustration ipconfig.gif

Migrating Repositories

During design time, the Oracle repository is used to store metadata created when using Application Explorer to configure adapter connections, browse EIS objects, configure services, and configure listeners to listen for EIS events. The information in the repository is also referenced at runtime. For management purposes, you can migrate BSE and J2CA repositories that are configured for Oracle to new destinations without affecting your existing configuration. For example, you may want to migrate a repository from a test environment to a production environment.

Migrating a BSE Repository

To migrate a BSE repository:

1. Copy the BSE control service URL, for example:

   http://localhost:7777/ibse/IBSEServlet/admin/iwcontrol.ibs
   
   

2. Open a third party XML editor, for example, XMLSPY.

   
   Description of the illustration xmlspy1.gif
   
   

3. In the menu bar, click SOAP.

   A list of options appears.

   
   Description of the illustration xmlspy2.gif
   
   

4. Select Create new SOAP request.

   The WSDL file location dialog box is displayed.

   
   Description of the illustration xmlspy3.gif
   
   

   1. In the Choose a file field, paste the BSE control service URL.

   2. Append ?wsdl to the URL, for example:

      http://localhost:7777/ibse/IBSEServlet/admin/iwcontrol.ibs?wsdl
      
      

5. Click OK.

   The soap operation name dialog box is displayed and lists the available control methods.

   
   Description of the illustration xmlspy4.gif
   
   

6. Select the MIGRATEREPO(MIGRATEREPO parameters) control method and click OK.

   
   

   Note: The MIGRATEREPO(MIGRATEREPO parameters) control method is available from the BSE administration console. This control method migrates all Web services to the new ( empty) repository. You can choose to migrate select Web services only.

   
   

   The following window shows the structure of the SOAP envelope.

   
   Description of the illustration xmlspy5.gif
   
   

7. Locate the Text view icon in the toolbar.

   
   Description of the illustration xmlspy6.gif
   
   

8. To display the structure of the SOAP envelope as text, click the Text view icon.

   The <SOAP-ENV:Header> tag is not required and can be deleted from the SOAP envelope.

9. Locate the following section:

   <m:MIGRATEREPO xmlns:m="urn:schemas-iwaysoftware-com:jul2003:ibse:config" version="">
   <m:repositorysetting>
   <m:rname>oracle</m:rname>
   <m:rconn>String</m:rconn>
   <m:rdriver>String</m:rdriver>
   <m:ruser>String</m:ruser>
   <m:rpwd>String</m:rpwd>
   </m:repositorysetting>
   <m:servicename>String</m:servicename>
   </m:MIGRATEREPO>
   
   

   Perform the following steps:

   1. For the <m:rconn> tag, replace the String placeholder with a repository URL where you want to migrate your existing BSE repository.

      The Oracle repository URL has the following format:

      jdbc:oracle:thin:@[host]:[port]:[sid]
      
      

   1. For the <m:rdriver> tag, replace the String placeholder with the location of your Oracle driver.

   1. For the <m:ruser> tag, replace the String placeholder with a valid user name to access the Oracle repository.

   1. For the <m:rpwd> tag, replace the String placeholder with a valid password to access the Oracle repository.

10. Perform one of the following migration options.

    • If you want to migrate a single Web service from the current BSE repository, enter the Web service name in the <m:servicename> tag, for example:

      <m:servicename>JDEService1</m:servicename>
      
      

    • If you want to migrate multiple Web services from the current BSE repository, duplicate the <m:servicename> tag for each Web service, for example:

      <m:servicename>JDEService1</m:servicename>
      <m:servicename>JDEService2</m:servicename>
      
      

    • If you want to migrate all Web services from the current BSE repository, remove the <m:servicename> tag.

      
      Description of the illustration xmlspy8.gif
      
      

11. In the menu bar, click SOAP and select Send request to server.

    Your BSE repository and any Web services you specified are now migrated to the new Oracle repository URL you specified.

Migrating a J2CA Repository

To migrate a J2CA repository:

1. Navigate to the location of your J2CA configuration directory where the repository schemas and other information is stored, for example:

   OracleAS_home\adapters\application\config\JCA_CONFIG
   
   

   Where JCA_CONFIG is the name of your J2CA configuration.

2. Locate and copy the repository.xml file.

3. Place this file in a new J2CA configuration directory to migrate the existing repository.

   Your J2CA repository is migrated to the new J2CA configuration directory.