10 Configuring Authorization Using Oracle Web Services Manager

These sections describe how to configure authorization. Authorization (also referred to as access control) enables you to determine what operations authenticated clients can access.

10.1 Overview of Authorization

Frequently, authentication is the first step of determining whether a user should be given access to a web service. After the user is authenticated, the second step is to verify that the user is authorized to access the web service. This is accomplished using an authorization policy

You can create an authorization policy using the binding_authorization_template or the component_authorization_template assertion template.

Policies created with these templates perform role- or permission-based access control (RBAC) and check that the authenticated user has been granted one of the roles or permissions allowed to access the web service.

For summaries of the authorization policies available in the current release, see "Authorization Policies" in Determining Which Predefined Policies to Use for a Web Service. Oracle Web Services Manager Predefined Policies, summarizes the security policies that enforce authorization, and indicates whether the policy is enforced at the transport layer or SOAP header.

For more information about authorization, see "Understanding Authorization" in Understanding Oracle Web Services Manager.

Note:

The authorization polices can follow any authentication policy where the subject is established.

You cannot attach both a permitall and denyall policy to the same web service.

10.2 Determining Which Resources to Protect

The authorization policies provide the following properties that you can use to specify which resources you want the policy to protect. Not all of the predefined policies feature all of the properties.

Note:

The predefined policies are read-only and cannot be edited. You can, however, create new policies using the predefined policies as a base. For information about creating a new policy, see Creating and Editing Web Service Policies. Once you have created the new policy, you can edit the policy and modify the settings or set the configuration properties as desired.

Constraint Match -- Expression that represents the constraints against which authorization checks are performed. The constraints expression is specified using the following two messageContext properties:
- messageContext.authenticationMethod—Determines the authentication method used to authenticate the user. The only valid value is SAML_SV.
- messageContext.requestOrigin—Determines whether the request originated from an internal or external network. This property is valid only when using Oracle and the Oracle HTTP server administrator has added a custom VIRTUAL_HOST_TYPE header to the request. For details about adding this header to a request, see Configuring the Oracle HTTP Server to Specify the Request Origin.
Note the following:
- The Constraint Match properties and their values are case sensitive.
- The constraint expression uses the following standard supported operators: ==, !=, &&, || and !.
In the following example, the role-based authorization assertion will be executed only if the current message does not contain a SAML_SV token OR the request origin is not internal.
```
${!(messageContext.authenticationMethod =='SAML_SV'|| messageContext.requestOrigin == 'internal')}
```
Note:

This property is valid for authorization policies based on the binding_authorization_template only. For policies based on other authorization assertion templates, this property is reserved for future use.
Action Match -- The web service operation for which permission-based checks are performed. This value can be a comma-separated list of values. This field accepts wildcards. * means all web service operations.

The valid values for Action Match are determined by the web service methods. For example, if the web service method is validate(amountAvailable), enter the Action Pattern as validate.
Resource Match -- The name of the resource for which permission-based checks are performed. This field accepts wildcards, and the default is * for all resources in the web services protected by the policy.

By convention you enter the Resource Pattern as (namespace of web service + web service name).

For example, if the namespace of the web service is http://project11 and the web service name is CreditValidation, you would enter the Resource Name as http://project11/CreditValidation.

If you specify a specific Resource Match, the policy is enforced only for those web services that match the criteria. That is, entering a specific value in the Resource Match field limits the scope of the authorization policy. The default of * protects all resources (namespace of web service + web service name) of the bulk-attached web services.
Permission Class -- By default, it is oracle.wsm.security.WSFunctionPermission. The class must be in the classpath.
Roles -- Possible values are Permit All, Deny All, and Selected Roles. If you choose Selected Roles, you must then select from the enterprise (Global) roles defined in WebLogic Server, which may include the following:
- AdminChannelUser
- Anonymous
- AppTester
- CrossDomainConnector
- Deployer
- Monitor
- Operator
- OracleSystemRole

10.3 Determining Authorization Permissions

Conceptually, determining whether an authenticated subject is authorized to access a particular resource protected by a web service policy has two parts that work in tandem.

The Resource Match, and Action Match parameters on the Assertions details page for the authorization policy determine what resources are being protected by the policy, as shown in Figure 10-1.

The oracle/binding_permission_authorization_policy also contains resource and action configuration properties that you can use to set a different action and resource. If you set these properties, or override them, the new values are used in the attached web service instead of the action and resource you configure using the Resource Match and Action Match parameters. For details about using configuration overrides, see Overriding Policy Configuration Properties.

You have the option to change the Permission Class setting for the policy, which identifies the permission class as per JAAS standards. The permission class must be available in the application or server classpath.

The custom permission class must extend the abstract Permission class and implement the Serializable interface. See the Javadoc at http://docs.oracle.com/javase/7/docs/api/java/security/Permission.html. The default is oracle.wsm.security.WSFunctionPermission.

Figure 10-1 The Permission Settings for a Policy

Description of "Figure 10-1 The Permission Settings for a Policy"
The OPSS Application Policies page specifies whether the authenticated subject has invoke access to the Resource Name listed there, as shown in Figure 10-2.

Figure 10-2 Adding a Permission on the OPSS Create Application Grant Page

Description of "Figure 10-2 Adding a Permission on the OPSS Create Application Grant Page"

OPSS uses the authorization policy's Assertions details page for the web service to determine which resources require an authorization check. Then, access to the resource is allowed if the authenticated subject has been granted WSFunctionPermission (or other permission) for that resource via OPSS.

Note:

If you changed the Permission Check Class configuration property for the policy to a custom class, use the custom class here as well.

Consider further the example shown in Figure 10-1 and Figure 10-2.

On the Assertions details page for the authorization policy, assume that you specify the following to protect the validate method of the http://project11/CreditValidation web service:

Action Match:        validate
Resource Match:       http://project11/CreditValidation
Permission Class  oracle.wsm.security.WSFunctionPermission

Then, on the OPSS Application Policies page, you would use http://project11/CreditValidation#validate for the Resource Name to specify that the authenticated subject has permission to invoke this resource:

Permission Class: oracle.wsm.security.WSFunctionPermission
Resource Name:    http://project11/CreditValidation#validate 
Permissions Action:  invoke

You can grant the WSFunctionPermission permission to a user, a group, or an application role. If you grant WSFunctionPermission to a user or group it will apply to all applications that are deployed in the domain.

10.4 Determining the OPSS Resource Name

the resource target of the WSFunctionPermission is enhanced to include the actual web service operation name. The OPSS resource name can include the operation name.

Note:

The OPSS resource name can include the operation name.

In previous releases of Fusion Middleware Control, the Resource Name on the OPSS Application Policies page was determined by name-space-of-webservice/ServiceName. For example, if the name space of a web service was http://project1/ and the service name was CreditValidation, the Resource Name would have been http://project1/CreditValidation. You could also use an asterisk (*) wildcard for providing permission to all the actions or all resources.

In this release, the resource target of the WSFunctionPermission is enhanced to include the actual web service operation name. The syntax for the Resource Name is now name-space-of-webservice/servicename#[operation name].

For a component it is compositename/componentname#[operation name.]

You must now include at least the name-space-of-webservice/service name. That is, you can no longer use an asterisk (*) wildcard for providing permission to all the actions or all resources.

Instead, to specify all operations for a web service, simply leave the operation name blank. For example, name-space-of-webservice/servicename#

Permission Action is always invoke.

10.5 About Configuring Fine-Grained Authorization Using Oracle Entitlements Server

Oracle Entitlements Server (OES) is a fine-grained authorization service you can use to secure applications and services end-to-end across the enterprise. OES is integrated with OWSM, and you can use OES together with OWSM for fine-grained authorization.

As described in "Understanding Oracle Entitlements Server Integration" in Understanding Oracle Web Services Manager, Oracle Entitlements Server (OES) is a fine-grained authorization service you can use to secure applications and services end-to-end across the enterprise. OES is integrated with OWSM, and you can use OES together with OWSM for fine-grained authorization.

"Understanding Oracle Entitlements Server Integration" describes the conceptual information you will need to configure OES integration, including a description of how resources are handled. That section also describes the division of labor: you configure the OES policies and Obligations from the OES console, and the OWSM OES policies from Fusion Middleware Control, WLST, or a tool such as JDeveloper. If you have not already done so, read that section first.

This section describes how to configure OES integration, and includes the following topics:

10.5.1 Prerequisites for Configuring OES Integration

In addition to your OWSM installation, you must also have an existing OES console configured, version 11.1.2.2.0 or later. OES must be installed on the same machine and to the same Oracle Middleware home as OWSM.

OES is a part of the Oracle Identity and Access Management Suite, and is covered in the following documentation. This section assumes that you are already familiar with this content and with configuring and administering OES.

See "Installing and Configuring Oracle Entitlements Server" in Installation Guide for Oracle Identity and Access Management for installation information.
See Administrator's Guide for Oracle Entitlements Server for configuration and management information.

10.5.2 Understanding Attributes for Obligations

OES allows you to create an Obligation in the OES console and provide multiple attribute name/value pairs. The attributes can be obtained from an XPath, an HTTP header, a message context, and constants (name/value), plus the set of static attributes (serviceURL, and so forth) that are always passed in authorization requests.

As described in "How Attributes Are Processed", OES allows you to create an Obligation in the OES console and provide multiple attribute name/value pairs. The attributes can be obtained from an XPath, an HTTP header, a message context, and constants (name/value), plus the set of static attributes (serviceURL, and so forth) that are always passed in authorization requests.

The easiest way to determine the information for the attributes is to deploy the application. Then, examine the SOAP request or the WSDL and determine what attributes you want. There are two approaches:

Deploy the application and use JDeveloper (or another mechanism) to look at the SOAP messages and determine what you need.
Deploy the application and look at the WSDL of the deployed application to determine what you need.

You can display the WSDL document for the web service endpoint as described in "Viewing the Web Service WSDL Document" in Administering Web Services with Oracle Fusion Middleware.

10.5.3 About Configuring OES Policies For Fine-Grained Authorization

There are two ways to contact OES for the authorization decision: a two-step (fine-grained) method and a single-step (coarse-grained) method. This section describes how to configure the OES policies for fine-grained authorization

As described in "OES Integration: The Big Picture" in Understanding Oracle Web Services Manager, there are two ways to contact OES for the authorization decision: a two-step (fine-grained) method and a single-step (coarse-grained) method. This section describes how to configure the OES policies for fine-grained authorization.

You specify which method to use via the use.single.step attribute in the oracle/binding_oes_authorization_policy and oracle/component_oes_authorization_policy policies when you later attach the OWSM policy, as described in Understanding How to Attach OWSM OES Policy. However, you need to decide on the method you plan to use so that you can configure the OES authorization policy accordingly.

The two-step method is the more common scenario, and you therefore typically configure two OES authorization policies: one for defining Obligations and another for the actual authorization decision.

You use the OES console to create the basic artifacts (application, resource type, and so forth) and to add actions to the resource type and define the resource.

This section describes the following topics:

10.5.3.1 Configuring the OES Resource for Masking

You must map the OES resource name to the OWSM resource name. When making an authorization call from OWSM, the resource name is passed to OES, and this name must exactly match the one defined in the OES policy.

As described in "Resource Mapping and Naming", you must map the OES resource name to the OWSM resource name. When making an authorization call from OWSM, the resource name is passed to OES, and this name must exactly match the one defined in the OES policy.

For the purpose of example, assume that you have a deployed SOAP web service with the following characteristics:

The deployed application is named HelloWorldServiceEar.
The resource type is WS_SERVICE.
The web service name is HelloWorldService.
The web service port name is SayHelloPort.
The operations in the web service are sayHello and sayHelloBytes.

Perform the following steps to configure the OES resource:

Create the OES application name. The application name must match that of the deployed application. For example, HelloWorldServiceEar.

Figure 10-3 Create OES Application

Description of "Figure 10-3 Create OES Application"
Create the OES resource type. The resource type must be WS_SERVICE.
Add actions for the WS_SERVICE resource type. The actions must be request.lookup and authorize.
Set the Supports Resource Hierarchy control.

By using the hierarchy, you can define the policy at the resource level or at the sub-resource (operation) level.

The OWSM resource name includes the service name/port name/operation name. However, you do not have to define the resource to this granular level in the OES console. For example, you can define a policy with the service name that applies to all resources that start with that service. Or, you can define a policy for a resource name with the service name and port name and this policy would apply to all operations of that service.

Setting the Supports Resource Hierarchy control is described in "Creating a Resource Type" in Administrator's Guide for Oracle Entitlements Server.
Create the resource. The resource name can include the service name/port name/operation name.

10.5.3.2 Creating Authorization Policy to Return Obligations

This procedure helps you to create authorization policy to Return Obligations.

To create authorization policy to Return Obligations, follow these steps:

Create a new OES authorization policy for the application you created in "Configuring the OES Resource for Masking".

Add the principals (roles and users) who should have access to the resource.

Add the targets (with actions) to be protected by this policy.

Figure 10-4 shows an example screen.

Figure 10-4 Adding Authorization Policy for Obligations

Description of "Figure 10-4 Adding Authorization Policy for Obligations"

From the Obligations tab, add Obligations.

As described in "How Attributes Are Processed", OES allows you to create an Obligation in the OES console and provide multiple attribute name/value pairs.

The attributes can be obtained from an XPath, an HTTP header, a message context, and constants (name/value), plus the set of static attributes (serviceURL, and so forth) that are always passed in authorization requests. These attributes must follow a specific naming convention, as described in "Attribute Types Supported for OES Policies" in Understanding Oracle Web Services Manager.

For the purpose of example, consider how Figure 10-5 is derived from and reflects the sample obligations shown in the following table in this section.

Remember that you must use these specific Obligation names, and case is insensitive. You can choose your own attribute names. The attribute values must match those of the request.

Note:

The OES console requires that Obligation names be unique across an application. If you want to define more than one OES policy for the same application to return Obligations of the same type, you cannot use the same name. For example, if you add the xpath Obligation in policy1, you cannot also add it to policy2 of the same application.

To make the Obligation name unique, use this naming convention:

<attribute_type>:<obligation_name>

where attribute_type is one of the supported types such as XPath, HTTPHeader or MessageContext. obligation_name can be any name to make it unique.

If an application has only a single OES policy to return Obligations and there is no chance of conflict, you can use the attribute type alone as the Obligation name.

Obligation Name	Attribute Name	Attribute Value
xpath	input	//env:Envelope//env:Body/ns3:sayHello/arg0/text()
xpath	namespace	saml=urn:oasis:names:tc:SAML:1.0:assertion env=http://schemas.xmlsoap.org/soap/envelope/ ns3=http://helloworldservice.jaxws.wsmtest/ Separate each attribute name with a comma (,). For example, `saml=... ,env=.. ,ns3=`.
xpath	saml_issuer	//saml:Assertion/@Issuer
`Httpheader`	proxy_auth	Proxy-Authorization
`Httpheader`	authHeader	Authorization
`messageContext`	authMethod	oracle.wsm.internal.authentication.method
`messageContext`	endpoint	oracle.j2ee.ws.runtime.endpoint-url
`MyStaticOb`	org	oracle
`MyStaticOb`	country	US

Figure 10-5 Sample Obligations For Authorization Policy

Description of "Figure 10-5 Sample Obligations For Authorization Policy"

10.5.3.3 Creating Actual OES Authorization Policy for Coarse-Grained Authorization

This procedure helps you to Create the OES authorization policy to perform the actual authorization.

This policy uses the Obligations provided by OWSM to make the real authorization decision.

In addition, OWSM passes to OES the authenticated subject, the target resource and requested action, as well as a set of implicit attributes (as described in "Attribute Types Supported for OES Policies") that are always passed in authorization requests. Your authorization policy can use these values in the authorization decision. You can also use OES predefined attributes such as time, date, and so forth.

Perform the following steps to create the OES authorization policy for the actual authorization:

Add the attributes that you plan to use in your authorization condition. They must match the Obligations you created in "Creating Authorization Policy to Return Obligations".
For example, to match the Obligations you created in Creating Authorization Policy to Return Obligations you would need to add the following attributes:
- saml_issuer
- input
- authHeader
- endpoint
- country
Note:

If you plan to use any of the implicit attributes (as described in "Attribute Types Supported for OES Policies"), you must add them as well.

All Attributes and Functions (both custom and predefined) are created, collected and further managed under the Extensions node of the Application. For more information, see "Managing Attributes and Functions as Extensions" in Administrator's Guide for Oracle Entitlements Server.

In the OES navigation pane, expand the application for which you are creating the authorization policy. Expand Extensions, then select Attributes and click the icon to create the new attributes.

You can choose Save and create another from the drop-down control to create multiple attributes from the single page.

Figure 10-6 Create New Attributes

Description of "Figure 10-6 Create New Attributes"
Add all of the new attributes to your resource type.
Create a new OES authorization policy for the application you created in Configuring the OES Resource for Masking.

Add the principals (roles and users) who should have access to the resource.

Add the targets (with actions) to be protected by this policy.

Figure 10-7 shows an example screen. The policy is set up to evaluate the authorization of user weblogic upon access to the sayHello and sayHelloBytes resources of HelloWorldService.

Figure 10-7 Adding Actual Authorization Policy

Description of "Figure 10-7 Adding Actual Authorization Policy"
From the Conditions tab for this policy, click Edit to create a new condition.
Complete the condition based on the attributes you added in Step 1, as shown in Figure 10-8.

Figure 10-8 Create the Condition

Description of "Figure 10-8 Create the Condition"

In this example, the policy returns PERMIT if:
- The user is weblogic.
- The resource is HelloWorldServiceEar/ HelloWorldService/SayHelloPort.
- The SAML issuer is www.oracle.com.
- The request SOAP message has "OWSM" at //env:Body/ns3:sayHello/arg0.
- Other conditions are met.
Attach the OWSM OES policy, as described in Understanding How to Attach OWSM OES Policy.

10.5.4 About Configuring OES Policies For Coarse-Grained Authorization

This section helps you understand how to configure OES policies for Coarse-Grained Authorization.

This section describes the following topics for coarse-grained authorization:

10.5.4.1 Configuring the OES Resource for Coarse-Grained Authorization

This procedure helps you to configure the OES resource for Coarse-Grained Authorization.

For the purpose of this example, assume that you have a deployed SOAP web service with the following characteristics:

The deployed application is named HelloWorldServiceEar.
The resource type is always WS_SERVICE.
The web service name is HelloWorldService.
The web service port name is SayHelloPort.
The operations in the web service are sayHello and sayHelloBytes.

Perform the following steps to configure the OES resource:

Create the OES application name. The application name must match that of the deployed application. For example, HelloWorldServiceEar.

Figure 10-9 Create OES Application

Description of "Figure 10-9 Create OES Application"
Create the OES resource type. The resource type must be WS_SERVICE.
Add the action for the resource type. The action must be authorize.
Set the Supports Resource Hierarchy control.

By using the hierarchy, you can define the policy at the resource level or at the sub-resource (operation) level.

The OWSM resource name includes the service name/port name/operation name. However, you do not have to define the resource to this granular level in the OES console. For example, you can define a policy with the service name that applies to all resources that start with that service. Or, you can define a policy for a resource name with the service name and port name and this policy would apply to all operations of that service.

Setting the Supports Resource Hierarchy control is described in "Creating a Resource Type" in Administrator's Guide for Oracle Entitlements Server.
Create the resource. The resource name must be of the form service name/port name/operation name, depending on how you want to utilize the resource hierarchy.

10.5.4.2 Creating Actual OES Authorization Policy for Fine-Grained Authorization

This procedure helps you to Create the OES authorization policy to perform the actual authorization.

To create the OES authorization policy to perform the actual authorization, follow this procedure:

OWSM passes to OES the authenticated subject, the target resource and requested action, as well as a set of implicit attributes (as described in "Attribute Types Supported for OES Policies") that are always passed in authorization requests.

Your authorization policy can use these values in the authorization decision. You can also use OES predefined attributes such as time, date, and so forth.

Perform the following steps to create the OES authorization policy for the actual authorization:

If you plan to use any of the implicit attributes (as described in "Attribute Types Supported for OES Policies"), you must add them.

Note:

All Attributes and Functions (both custom and predefined) are created, collected and further managed under the Extensions node of the Application. For more information, see "Managing Attributes and Functions as Extensions" in Administrator's Guide for Oracle Entitlements Server.

In the OES navigation pane, expand the application for which you are creating the authorization policy. Expand Extensions, then select Attributes and click the icon to create the new attributes.

You can choose Save and create another from the drop-down control to create multiple attributes from the single page.
Add all of the implicit attributes you plan to use to your resource type, as shown in Figure 10-10.

Figure 10-10 Add Implicit Attributes Needed for Conditions

Description of "Figure 10-10 Add Implicit Attributes Needed for Conditions"
Create a new OES authorization policy for the application you created in Configuring the OES Resource for Coarse-Grained Authorization.

Add the principals (roles and users) who should have access to the resource.

Add the targets (with actions) to be protected by this policy.

Figure 10-11 shows an example screen.

Figure 10-11 Adding Actual Authorization Policy

Description of "Figure 10-11 Adding Actual Authorization Policy"
Attach the OWSM OES policy, as described in Understanding How to Attach OWSM OES Policy.

10.5.5 About Configuring OES Policy For Masking

This section helps you to know about how to configure the OES policy for masking.

This below given sections describe how to configure the OES policy for masking:

10.5.5.1 Configuring the OES Resource

You must map the OES resource name to the OWSM resource name. When making a masking call from OWSM, the resource name is passed to OES, and this name must exactly match the one defined in the OES policy.

As described in "Resource Mapping and Naming", you must map the OES resource name to the OWSM resource name. When making a masking call from OWSM, the resource name is passed to OES, and this name must exactly match the one defined in the OES policy.

For the purpose of example, assume that you have a deployed SOAP web service with the following characteristics:

The deployed application is named HelloWorldServiceEar.
The resource type is always WS_SERVICE.
The web service name is HelloWorldService.
The web service port name is SayHelloPort.
The operations in the web service are sayHello and sayHelloBytes.

Perform the following steps to configure the OES resource:

If you have not already done so, create the OES application name. The application name must match that of the deployed application. For example, HelloWorldServiceEar.

Figure 10-12 Create OES Application

Description of "Figure 10-12 Create OES Application"
If you have not already done so, create the OES resource type. The resource type must be WS_SERVICE.
If you have not already done so, add actions for the resource type. The actions must be response.lookup and mask.
If you have not already done so, set the Supports Resource Hierarchy control.

Setting the Supports Resource Hierarchy control is described in "Creating a Resource Type" in Administrator's Guide for Oracle Entitlements Server.
If you have not already done so, create the resource. The resource name must be of the form service name/port name/operation name, depending on how you want to utilize the resource hierarchy.

10.5.5.2 Creating Masking Policy to Return Obligations

This procedure helps you to create a masking policy to return obligations.

To create a masking policy to Return Obligations, perform the following steps:

Create a new OES policy for the application you created in Configuring the OES Resource.

Add the principals (roles and users) who should have access to the resource.

Add the targets (with action response.lookup) to be protected by this policy.
From the Obligations tab, add Obligations.

As described in "How Attributes Are Processed", OES allows you to create an Obligation in the OES console and provide multiple attribute name/value pairs.

For this masking use case, create a set of XPath queries to get the attributes you may want to mask.

As a result of these Obligations, OWSM gets all of defined attributes and Xpath queries and runs them on the current response SOAP message. (If nothing is returned in this call then execution stops and no masking is performed.) OWSM uses the result of this query to call the actual masking policy described in Creating Actual OES Masking Policy.

You use the attribute names from this Obligation when you create the Obligation for the actual masking policy.

10.5.5.3 Creating Actual OES Masking Policy

This procedure helps you to create Actual OES masking policy.

Create the OES authorization policy to perform the actual masking.

This policy uses the Obligations provided by OWSM to make the real masking decision.

Perform the following steps to create the OES policy for the actual masking:

Add the attributes that you plan to use in your condition.

If you plan to use any of the implicit attributes (as described in "Attribute Types Supported for OES Policies"), you must add them as well.

Note:

All Attributes and Functions (both custom and predefined) are created, collected and further managed under the Extensions node of the Application. For more information, see "Managing Attributes and Functions as Extensions" in Administrator's Guide for Oracle Entitlements Server.

In the OES navigation pane, expand the application for which you are creating the authorization policy. Expand Extensions, then select Attributes and click the icon to create the new attributes.

You can choose Save and create another from the drop-down control to create multiple attributes from the single page.
Add all of the new attributes to your resource type.
Create a new OES authorization policy for the application you created in Configuring the OES Resource.

Add the principals (roles and users) who should have access to the resource.

Add the targets (with action mask) to be protected by this policy.
From the Obligations tab, add Obligations.

These Obligations specify whether the attribute should be passed as-is or masked. OWSM honors the Obligation returned by OES and masks attributes marked sensitive by OES.

Return the value with which you want to replace an attribute.

For example, if in the obligation policy you added an XPath as name=//env:Envelope//env:Body/ns3:sayHelloResponse/return/text(), in the masking policy you might add the Obligation in an XPath as name=xxxxx or name=****, where name matches in both policies.
Attach the OWSM OES policy, as described in Understanding How to Attach OWSM OES Policy.

10.5.6 Understanding How to Attach OWSM OES Policy

This section helps you understand how to attach OWSM OES policy.

This section describes how to attach an OWSM OES policy:

10.5.6.1 Attaching the OWSM OES Policy

This procedure helps you to attach OWSM OES Policy.

Make a copy of the preconfigured oracle/binding_oes_authorization_policy, oracle/component_oes_authorization_policy or oracle/binding_oes_masking_policy and then attach the copy to your web service. Perform the following steps:

In the navigator pane, expand WebLogic Domain to show the domain for which you need to configure OES integration. Select the domain.
In the content pane, click WebLogic Domain, then Web Services, and then Policies.
Select the oracle/binding_oes_authorization_policy, oracle/component_oes_authorization_policy or oracle/binding_oes_masking_policy policy and make a copy.
Edit the attributes of the copy. (You can instead choose to override the attributes, as described in a subsequent step.)

The use.single.step attribute controls the way in which you contact OES for the authorization decision: a two-step (fine-grained) method and a single-step (coarse-grained) method. The default is false, which uses the two-step (fine-grained) method. In the one-step method you do not use Obligations but you can use the implicit attributes in the conditions.

You can set this attribute in the oracle/binding_oes_authorization_policy and oracle/component_oes_authorization_policy policies. The oracle/binding_oes_masking_policy is always two-step.

The OES Based Authorization setting uses the guard element (see orawsp:guard) to define resource, action, and constraint match values. These values allow the assertion execution only if the result of the guard is true. That is, if the accessed resource name and action match, only then is the assertion allowed to execute. By default, resource name and action use the wildcard asterisk "*" and everything is allowed.

If you followed the resource naming convention when creating the OES policy, you do not need to explicitly set the resource name.
Attach the policy at design time or post-deployment, as described in Attaching Policies to Manage and Secure Web Services.

Attach the OWSM oracle/binding_oes_authorization_policy or oracle/component_oes_authorization_policy policy, alone or combination with the oracle/binding_oes_masking_policy policy.
Optionally, use Fusion Middleware Control, WLST, or JDeveloper (or another mechanism) to override attributes. If you followed the resource naming convention when creating the OES policy, overriding resource properties is not required.

See Configuration Properties and Overrides for a description of the attributes you can override.

See Overriding Policy Configuration Properties for information on overriding configuration policies.
Also attach any of the authentication policies at design time or post-deployment, as described in Attaching Policies to Manage and Secure Web Services.

10.5.6.2 Configuration Properties and Overrides

You can set the configuration properties as described in this section.

You can set the configuration properties shown in Table 10-1 for the policies when you attach the policy, or override them.

If you followed the resource naming convention when creating the OES policy, the resource names are derived and overriding the properties is not required.

If you override some but not all values, the remainder are derived.

Table 10-1 OWSM OES Configuration Properties

Name	Description
`application.name`	The deployed application name defined in OES. (For SOA, the composite name is used as the application name.) Value can be static or dynamic that uses ${} notation.
`resource.type`	Resource type defined in OES. Value can be static or dynamic that uses ${} notation. For SOAP application, must be `WS_SERVICE`. For SOA component, must be `COMPONENT`.
`resource.name`	Resource name defined in OES. Value can be static or dynamic that uses ${} notation. For SOAP and SOA reference, must be of the form `web-service-name/port/web service operation`. For SOA component, must be of the form `SOA component name/web service operation`.
`lookup.action`	Action that will be used during attributes lookup. Can be `request.lookup` or `response.lookup`. Value can be static or dynamic that uses ${} notation.
`execute.action`	Action that will be used during real authorization or masking. Default values are `authorize` for authorization and `mask` for masking use case. Value can be static or dynamic that uses ${} notation.
`use.single.step`	Set value to true to skip lookup phase. Does not apply to masking policy.
`reference.prioroty`	Optional property that specifies the priority of the policy attachment.

These properties allow both static and dynamic values. Dynamic values use one or more ${} operators and allow separator characters such as a period or slash. For example, if you specify the value of resource.name as ${PORT}/${OPERATION}, then it could resolve to myPort/operation. As another example, ${MODULE}.${SERVICE} could resolve to myModule.myService.

The possible dynamic values are as follows:

APPLICATION
MODULE
SERVICE (For SOAP and SOA reference, it is WSDL web service name.
PORT (WSDL service port name)
OPERATION (web service operation for SOAP.)
COMPOSITE (SOA composite name)
COMPONENT (SOA component name)
NAMESPACE

10.6 Configuring the Oracle HTTP Server to Specify the Request Origin

This procedure helps you to configure the Oracle HTTP Server to specify the request origin.

The Constraint Match property setting contains a requestOrigin field that specifies whether the request originated from an internal or external network. This property is valid only when using Oracle HTTP Server and the Oracle HTTP Server administrator has added a custom VIRTUAL_HOST_TYPE header to the request.

To configure the Oracle HTTP Server to specify the request origin, the administrator must modify the httpd.conf file as follows:

Verify that the module mod_headers is loaded.
Set the VIRTUAL_HOST_TYPE header name in the RequestHeader. Valid values are internal and external. Use the following command syntax:
```
RequestHeader set|append|add|unset header [value [env=[!]variable]]
```
For example, to configure the virtual host for internal requests:
```
<VirtualHost *:7777>
RequestHeader set VIRTUAL_HOST_TYPE  "internal" 
</VirtualHost>
```
To configure the virtual host for external requests:
```
<VirtualHost *:8888>
RequestHeader set VIRTUAL_HOST_TYPE "external"
</VirtualHost>
```
In these examples, all the requests coming from outside of the private network are routed through virtual host:8888 and all the requests coming from the internal private network are routed through virtual host:7777.

Note that you must also add these ports in the httpd.conf file as listen ports so that the applications are available on the ports externally.
Restart the Oracle HTTP Server.

10.7 Using OAuth2 with Oracle Web Services Manager

This section describes how to use the Oracle Mobile and Social OAuth2 authorization framework with Oracle Web Services Manager.

This section describes how to use the Oracle Mobile and Social OAuth2 authorization framework with Oracle Web Services Manager, including:

Note:

This section assumes that you are familiar with both the terminology and the conceptual and configuration information described in the following sections of Administrator's Guide for Oracle Access Manager with Oracle Security Token Service:

10.7.1 About OAuth2 with Oracle Web Services Manager

This section describes OAuth2 support in Oracle Web Services Manager based on "The OAuth 2.0 Authorization Framework" specification.

OAuth2 support in Oracle Web Services Manager is based on "The OAuth 2.0 Authorization Framework" specification, which is available at http://tools.ietf.org/html/rfc6749.

Oracle Web Services Manager uses the Oracle Mobile and Social OAuth2 service as the authorization server for the OAuth2.0 protocol interactions. For more information, see "Understanding Mobile and Social" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Oracle Web Services Manager allows web service clients to interact with the Mobile and Social OAuth2 server implementation for both SOAP and REST web services, for 2-legged authorization.

10.7.1.1 Understanding 2-legged OAuth2

In 2-legged OAuth2, the interaction is application-to-application without user consent.

The client requests authorization from the resource owner. In response, the client receives an authorization grant, which is a credential representing the resource owner's authorization. Then:

The client requests an access token (AT) by authenticating with the authorization server and presenting the authorization grant.
The authorization server authenticates the client and validates the authorization grant, and if valid, issues an AT.
The client requests the protected resource from the resource server and authenticates by presenting the AT.
The Oracle Web Services Manager server side agent validates the AT and accepts the request if valid or rejects the request if invalid.

You attach the OAuth2 client policy such as oracle/http_oauth2_token_client_policy and the oracle/oauth2_config_client_policy to the client application. The required token.uri property of the oracle/oauth2_config_client_policy policy specifies the OAuth2 server token endpoint.

You also attach any of the following Oracle Web Services Manager JWT service policies to the web service. The Oracle Web Services Manager server-side agent validates the access token.

oracle/http_jwt_token_service_policy
oracle/http_jwt_token_over_ssl_service_policy
oracle/multi_token_rest_service_policy
oracle/multi_token_over_ssl_rest_service_policy
oracle/wss11_saml_or_username_token_with_message_protection_service_policy
oracle/http_oauth2_token_client_policy
oracle/http_oauth2_token_opc_oauth2_client_policy
oracle/http_oauth2_token_identity_switch_opc_oauth2_over_ssl_client_policy
oracle/http_oauth2_token_opc_oauth2_over_ssl_client_policy
oracle/http_oauth2_token_identity_switch_over_ssl_client_policy
oracle/http_oauth2_token_over_ssl_client_policy
oracle/http_oauth2_config_client_policy

10.7.1.2 Supported Authorization Grant Types in 2-Legged Authorization

An authorization grant is a credential representing the resource owner's authorization.

Oracle Web Services Manager supports the following authorization grant types in 2-legged authorization. You specify which types you want to use when you configure the OAuth2 OWSM client profile, as described in Configuring OAuth2 for Use With Oracle Web Services Manager Policies

Client credentials grant - In this case the client credentials are sent in the "Authorization: Basic" HTTP header as explained in Client Credentials Grant - OAuth2.0 Authorization Framework.

You set the federated.client.token property in the attached oauth2 client policy to specify the user name and password to use.
Client credentials JWT (Federation use case) - In this case the client credentials are sent in the form of a JWT assertion, as explained in Using JWTs for Client Authentication.

Oracle Web Services Manager generates the JWT token locally based on client credentials stored in the Oracle Web Services Manager credential store. You set the client token policy federated.client.token property to specify whether a JWT token is generated for the client using the values of the oauth2.client.csf.key and keystore.sig.csf.key properties.

JWT token is generated for the client using the values of the oauth2.client.csf.key and keystore.sig.csf.key properties. Ensure that the property federated.client.token is set to true.
Client credentials are sent in the Basic Auth Header, plus user credentials in the JWT assertion, as explained in Client Credentials Grant - OAuth2.0 Authorization Framework and Using JWTs for Client Authentication.

You set the oauth2.client.csf.key property in the attached oauth2 client policy to specify the user name and password to use in the Basic Auth Header.
Client credentials are sent in the JWT assertion, plus user credentials in the JWT assertion, as explained in Using JWTs for Client Authentication.

10.7.1.3 How Client Credentials Are Determined in 2-Legged Authorization

The client credential is always included in the request to the OAuth2 server.

The federated.client.token property determines whether the JWT is used for the client ID in the client credential, or whether the client ID and password are used for the client credential.

If federated.client.token is true (the default), then the JWT is used for the client ID in the client credential.
If federated.client.token is false, then the client ID and password are used for the client credential.

10.7.1.4 Relationship of User Credentials, Client Credentials, and Subject in 2-Legged Authorization

The subject property specifies the location from which the subject used to create the JWT token is obtained.

The subject.precedence property specifies the location from which the subject used to create the JWT token is obtained.

As shown in Table 10-2, if subject.precedence is set to true, the user name to create the JWT token is obtained only from the authenticated subject.

If subject.precedence is set to false, the user name to create the JWT token is obtained only from the csf-key property.

Table 10-2 User Credential, Subject, and Access Token

subject.precedence	csf-key	Authenticated User Subject	Client Credential	User Credential	Access Token Principal/Subject
True (default)	N/A	Available	See How Client Credentials Are Determined in 2-Legged Authorization.	JWT for authenticated end user.	End-user name.
True (default)	N/A	N/A	See How Client Credentials Are Determined in 2-Legged Authorization.	Not included	Client ID
False	Not configured (default)	N/A	See How Client Credentials Are Determined in 2-Legged Authorization.	Not included	N/A
False	Configured	N/A	See How Client Credentials Are Determined in 2-Legged Authorization.	JWT for the identity from the csf-key entry.	The user name from the csf-key/user name is configured.

10.7.2 Configuring OAuth2 for Use With Oracle Web Services Manager Policies

As a prerequisite to configuring Mobile and Social OAuth2 for use with Oracle Web Services Manager, you should be familiar with the configuration information.

As a prerequisite to configuring Mobile and Social OAuth2 for use with Oracle Web Services Manager, you should be familiar with the configuration information described in Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

For detailed information about configuring OAuth2 for use with Oracle Web Services Manager, see "Configuring OAuth Services" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.