53 Secure Web Services Use Cases

The service use case patterns described in Common Service Use Cases and Design Patterns must be secured. Security requirements vary depending on service and client implementations.

The following Web service integration scenario represents a typical integration pattern. The scenario highlights the security implementation requirements of each service component, as illustrated in the accompanying figure below.

An example Web service integration scenario that relies on Oracle Mediator:

1. A user logs into an ADF web application.

2. The application raises a business event.

3. The business event triggers an SOA composite through an Oracle Mediator service component.

4. The Mediator component invokes a Business Process Execution Language (BPEL) process.

   The Mediator can invoke various BPEL processes based on the incoming event. It can also transform the event to the payload that BPEL process takes.

5. The BPEL process interacts with ADF Business Components Web services so as to execute the business logic of the use case.

While event generation typically begins with ADF Business Components, as an alternative, you can also trigger or call a SOA composite and either directly or indirectly invoke the ADF Business Components Web service by any one of the following:

• Another SOA composite through a business event.

• Java or PL/SQL code through a business event.

• Synchronously calling the SOA composite through a JAX-WS proxy.

• An ADF Web service data control.

These alternative flow patterns require different security implementations. For example, both JAX-WS proxy and ADF Web service data control can access the client security policy references in the connections.xml file of the application to propagate the current user. However, when the event is triggered from the user interface and ADF Business Components, the ADF Business Components Web service can be invoked synchronously using the ServiceFactory interface (using either RMI or SOAP).

The following figure illustrates the possible event generation scenarios for Oracle Fusion applications. The main scenario flow—ADF Business Components-generated events—is illustrated in the center, along with numbers (enclosed in circles) illustrating the corresponding steps of the above integration scenario. Possible alternative flows are represented by dashed lines and numbers.

Figure 53-1 Sample Web Service Integration Scenario

Oracle Fusion applications typically use SOAP services. Use Oracle Web Services Manager (Oracle WSM) to secure these services. Following are the main recommendations when using Oracle WSM with Oracle Fusion Applications.

• Attach Oracle WSM authentication service policies to Web services and BPEL process Web service bindings only when it is not possible to globally attach policies at the domain level.

• Attach Oracle WSM client policies to Web services references in BPEL Partner links, proxies and ADF Web services data controls.

• It is a requirement to enforce authentication on all ADF Business Components Web services and exposed BPEL processes. Global policy attachment automatically satisfied this requirement.

• It is a requirement to enforce authorization on all ADF Business Components Web services.

• No authorization is required for SOA components, although it is possible to implement authorization checks for users and enterprise roles. You can enable authorization checks in ADF Business Components Web services.

• All request and response messages must be protected for integrity and confidentiality using either message protection security policies or message protection and authentication with SSL security policies. Oracle WSM transparently handles this.

• Oracle WSM policies do not apply to events.

You can secure Web services and clients used in your Oracle Fusion application with Oracle Web Services Manager (Oracle WSM). A component of Oracle SOA Suite, Oracle Web Services Manager provides security policies that you can declaratively attach to SOAP services and clients.

Oracle Fusion Applications make use of an Oracle WSM feature called global policy attachments (GPA). Using GPA, policies are not attached locally, but are specified at a global level. At runtime, components simply inherit the global policy and Oracle WSM enforces it.

Unlike local policy attachments (LPA), which need to be added at every Web service client and server, global policy attachment (GPA) can be attached at a domain level. This makes it easy for the system administrator to have a uniform policy for all Web services across the domain.

Certain scenarios exist in which GPA cannot be used:

• Public Web services (those that do not need any user authentication) should use LPA to locally attach a "no authentication" policy on both the client side and the service side.

• When a Web service client needs to connect to a service using a particular user name and password, you need to specify the user name and password using a configuration override.

  But GPA policies do not allow configuration overrides, which means you must use LPA to attach a username password policy on the client side. Note that even though configuration overrides require that you implement LPA on the client side, you still can allow the system administrator to define GPA on the server side for username password policies. Unlike the client side, the server side need not specify a particular username and password, instead it will accept any username and password.

• When a Web service requires additional security hardening, because, for example, they want to use a key that is different from the domain key generated for Oracle Fusion Applications, then you must use LPA and specify this key using a configuration override.

  The Oracle Fusion Applications provisioning script generates a single keypair (public key and self signed certificate) with the alias orakey and stores the keypair in all Oracle Fusion Applications domains. All GPA policies will use this key by default unless you use LPA and specify a different key.

• When a Web service exists that must be invoked outside of an Oracle Fusion application that external service will be secured either with message protection or it must go through SSL to ensure protection. The default GPA for Oracle Fusion Applications is no message protection, which is not sufficient for external services that can be invoked outside Oracle Fusion applications. For external Web services, you must use LPA to use a message protection policy, for example to secure the external service to make it more secure or less secure.

• When a Fusion Web service can be invoked by an application outside of Oracle Fusion applications (because an Oracle Fusion application is integrated with the calling application) that service will most likely need to use policies to provide additional hardening. In this case, these clients should use LPA.

• Fusion Web service clients that need to connect to external non Fusion Web services will most likely need to use policies that are different from the globally attached policies. In this case, these clients should also use LPA.

You should use LPA whenever you want to override the globally attached policy. The user name and specifying an alternate key are common examples of overriding a globally attached policy.

In summary, use LPA when the Web service is a public service, when the service requires elevated privileges to connect using a particular user name and password, or when the service requires additional security hardening.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For background about globally policy sets, see the "Understanding Oracle WSM Policy Framework" chapter of the Administering Web Services, in the Oracle Fusion Middleware Online Documentation Library.

1. Application developer removes LPA from all clients and Web services (except for the situations that need to use LPA).

   A system administrator can do this using either Oracle Enterprise Manager Fusion Middleware Control or using WebLogic Scripting Tool (WLST).

2. Application developer makes sure that the no_authentication_service_policy policy has been attached to those services that do not require authentication.

   Note that unless you attach a no behavior policy (oracle/no_authentication_service_policy or oracle/no_authentication_client_policy), public Web services will inherit GPA and will no longer be accessible, thus it is necessary to perform this step before enabling GPA.

   Developers can do this in Oracle JDeveloper directly in the ADF Business Components Web service implementation class file, as described in Attaching Policies Locally. Also, a system administrator can do this either using Oracle Enterprise Manager Fusion Middleware Control or using WebLogic Scripting Tool (WLST).

3. System administrator decides which policy to attach globally.

   Profile choices are Authentication (AuthN), SSL and Message protection. Oracle Fusion Applications are configured to use the AuthN profile by default. For background about profiles choices, see Table 53-1.

4. System administrator creates the global policy sets.

   A system administrator does this using either Oracle Enterprise Manager Fusion Middleware Control or using WLST. They will need to define a separate GPA policy set for each kind of service–SOA service, SOA reference, ADF Business Components Web service, and so on.

5. Application developer in cooperation with the system administrator verifies that the client and Web services are using GPA.

   A system administrator does this using either Oracle Enterprise Manager Fusion Middleware Control or using WLST.

Because certain scenarios exist in which GPA cannot be used, Oracle Fusion application developers may need to use local policy attachment (LPA) for Web services and Web service clients. In some cases, LPA must be used on the service side and client side, while other cases exist where only the client side requires LPA.

You should use local policy attachment:

• When a Web service should be public (those that do not require user authentication)

• When a Web service client requires elevated privileges to connect using a particular user name and password (GPA only handles identity propagation, thus LPA is required when identity switching is required)

• When a Web service requires additional security hardening

• When Fusion Web service clients (for example, a JRF client or a SOA client) need to connect to external non Fusion Web services

The following table shows the recommended Oracle WSM policies and the components to which they apply.

wss_saml_or_username_
 token_service_policy

wss10_saml_token_
 client_policy

wss10_saml_token_
 client_policy

wss_saml_or_username_
 token_over_ssl_
   service_policy

oracle/wss_saml_token_over_ssl_client_policy

oracle/wss_username_token_over_ssl_client_policy

wss11_saml_or_
 username_token_with_
  message_protection_
    service_policy

wss11_username_token_with_message_protection_client_policy

wss11_saml_token_with_message_protection_client_policy

oracle/no_
 authentication_
  service_policy

oracle/no_
 authentication_
  client_policy

1. In the exported jazn-data.xml file, grant access to the Web service using the JDeveloper security policy editor. For details, see How to Grant Access for the Service.
2. Enforce ADF Security authorization for the Web service in the Web service implementation class. For details, see How to Enforce Authorization for the Service.

When a service is invoked there is security for the client side (caller) and for the server side (callee).

The client side can invoke the service through a SOAP service invocation, where the client can be a JAX-WS proxy or a SOA composite (service factory via SOAP is still JAX-WS proxy). Invoking the service, requires the client to pass the security context to the server side; the client side will either propagate the current user credential or switch identity, based on the client side authentication policy.

Alternatively, the client side can invoke the service through an RMI invocation. This type of invocation applies only to the ADF Business Component Web service. In this case, there is no client side authentication policy, since the client side always just propagates the identity to the server side.

Security for the server side is based on the Oracle WSM authentication policy. The server side first authenticates the user. A SOA composite service will not perform authorization, but ADF Business Components Web services will check whether the user is authorized to invoke the service. This type of service performs the authorization check using the EJB ServicePermissionCheckInterceptor interceptor before executing any service method.

The following figure illustrates how Oracle WSM policies are enforced within the Oracle Fusion Applications use case described in Introduction to Securing Web Services Use Cases.

Figure 53-2 Using Oracle Web Services Manager Security Policies

This example use case illustrates the following:

• Each SOAP client includes an attached client policy.

• Authorization is enforced in the ADF Business Components Web services only.

• SOA components have no authorization policies.

• Oracle Web Services Manager policies do not apply to events.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For more information about Oracle Web Services Manager policies, see the "Understanding Oracle WSM Policy Framework" chapter of the Administering Web Services, in the Oracle Fusion Middleware Online Documentation Library.

1. In the Application Resources panel of the Application Navigator, double-click the weblogic-application.xml file of the project that defines the incoming side of the Web service request.
2. In the source editor for the file, add the following lines alongside the other <library-ref> tags:

   <library-ref>
     <library-name>
       oracle.applcore.config
     </library-name>
   </library-ref>
   

   The order of the <library-ref> tags is not important; however, all <library-ref> tags must be grouped together.

3. Repeat this change in the project that defines the outgoing side of the Web service request.

   In order for propagation to work, both the client sending the request and the server receiving the request must have the oracle.applcore.config library.