Configuring Authorization Using Oracle Web Services Manager

10 Configuring Authorization Using Oracle Web Services Manager

You can configure authorization using OWSM. Authorization (also referred to as access control) enables you to determine what operations authenticated clients can access.

Topics:

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. For more information see "Installing and Configuring Oracle Entitlements Server" in Installation Guide for Oracle Identity and Access Management for installation 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

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

You can configure OES policies for Coarse-Grained Authorization.

Topics:

10.5.4.1 Configuring 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

Create the OES authorization policy to perform the actual authorization.

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

You can configure the OES policy for masking.

Topics:

10.5.5.1 Configuring the OES Resource

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

Create a masking policy to Return Obligations by performing 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

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

You can attach OWSM OES policy.

Topics:

10.5.6.1 Attaching the 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 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

You can 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 OAuth 2.0 with Oracle Web Services Manager

You can use the Oracle Mobile and Social OAuth2 authorization framework with Oracle Web Services Manager.

Topics:

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

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

As previously described, 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.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 About OWSM OAuth2 Client API

OAuth2 Client API feature allows to get access token without the need of creating any rest client, it enables consumer of API to fetch access token and use it in any outbound request. This OAuth2 access token can then be used by the API caller to call a service in the OAuth2 resource server protected by the OAuth2 Auth Server.

OWSM does the following:

Invoke OAuth2 server to authenticate and authorize to obtain Access Token.
Secure the messages to the Resource server with the Access Token.

OWSM cannot do either of the above functions independently. This OAuth2 Client API feature can be used to Invoke OAuth2 server to authenticate and authorize to obtain Access Token.

This section includes the following topic:

Configuring OWSM OAuth2 Client Credentials

10.7.2.1 Configuring OWSM OAuth2 Client Credentials

OWSM supports for OAuth2 on the client side as an integrated solution for the whole process. This OAuth2 Client API feature enables calls to be made independently to the OAuth2 server.

The process to configure OAuth2 client credentials and invoke the client app to get the Access Token consists of the following steps:

You must register your client under the register Client Section of the Oauth server and update the following fields:
- Name - Select a Client name which is different from the client ID.
- Accessible Resource - Select appropriate resources which are accessible to this client.
- Trusted client - You can ignore this check for the time being. You can click on it later and upload a certificate once your client side configurations are done.
- After providing all the necessary values, click on Register.
Attach client policies which will be used with OAuth 2 Client API.

Note:
OWSM policies can be attached using LPA or GPA. It is recommended that the oauth2 config policy should be attached as GPA and http_oauth2_token_over_ssl_client_policy attached as LPA.
You must Configure OAuth2 client credentials in client domain.
1. Click on Show Secret to get the client Id and secret of registered client with OAuth2 server.
  
  Note:
  The OAuth 2 client must be a trusted client to work with OWSM OAuth 2 Client API.
2. Now connect to client domain and execute the following WLST to configure client credentials in CSF store:
```
createCred(map="oracle.wsm.security", key="<replace with OAuth2 server>", user="<replace withe OAuth 2 client id>”, password="<replace with Oauth2
```
You must Setup KeyStore at Client Domain.

Note:
In 14c, KSS is the default keystore which is used.
1. Connect to the client domain and execute the following WLST :
```
svc = getOpssService(name='KeyStoreService')
```
```
svc.createKeyStore(appStripe='owsm', name='keystore', password='',permission=true)
```
2. Generate keypair:
```
svc.generateKeyPair(appStripe='owsm', name='keystore', password='', dn='CN=OWSM, OU=ST, O=Oracle, L=RedWood, ST=CA, C=US', keysize='2048', alias
```
  Note:
  Orakey is the default key alias, to sign the client request. The key will be used to sign the client and user assertion to be sent to the OAuth 2 server. As a trusted OAuth 2 client, the signing certificate must be uploaded to the OAuth 2 server.

Update client code to use OWSM OAuth2 client API.

This shows a sample servlet based application. Update your servlet client code as -

package client.jaxrs;
import java.io. IOException;
import java.io.PrintWriter;
import java.security.AccessController;
import java.util.Date;
import javax.security.auth.Subject;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import oracle.wsm.metadata.feature.PolicyReferenceFeature;
import oracle.wsm.metadata.feature.PolicySetFeature;
import oracle.wsm.metadata.feature.PropertyFeature ;
import oracle.wsm.security.oauth2.OAuth2ClientTokenManager;
import oracle.wsm.security.oauth2.OAuth2TokenContext;
import oracle.wsm.security.oauth2.OAuth2TokenResponse;
import oracle.wsm.security.util.SecurityConstants;
public class SampleClient extends HttpServlet {
public void init(ServletConfig config) throws ServletException {   
 super.init(config);
}
/**
* set OWSM Policy details
* @return
* @return
*/
private PolicySetFeature createOWSMPolicySetFeature() {
PropertyFeature  tenantName new  PropertyFeature (
SecurityConstants.ConfigOverride.CO_USER_TENANT_NAME, inoracleindiatrial52406”)
PolicyReferenceFeature[] clientPRF = new PolicyReferenceFeature[] {
new PolicyReferenceFeature (“oracle/http_oauth2_token_over_ssl_client_policy”,
new PropertyFeature[]{ tenantName}) };
     PolicySetFeature policySetFeature = new PolicySetFeature(clientPRF);     
     return policySetFeature;
}     
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {    
response.setContentType(“text/html;charset=UTF-8”);     
PrintWriter out = response.getWriter();       
try {     
OAuth2ClientTokenManager oauth2ClientTokenManager = OAuth2ClientTokenManager.getInstance ();
OAuth2TokenContext oauth2TokenContext = OAuth2ClientTokenManager.getOAuth2TokenContext ();
PolicySetFeature policySetFeature = createOWSMPolicySetFeature ();
oauth2TokenContext.setPolicySetFeature(policySetFeature);
oauth2ClientTokenManager.getAccessToken(oauth2TokenContext);
OAuth2TokenResponse oauth2TokenResponse = oauth2TokenContext.getOAuth2TokenResponse();
String accessToken = oauth2TokenResponse.getAccessToken ();
String tokenType = oauth2TokenResponse.getTokenType ();
long expiresIn = oauth2TokenResponse.getExpiresIn();
out.println (“<br><b> accessToken:<br><b>" + accessToken);
out.println (“<br><b> tokenType : <b>" + tokenType);
out.println (“<br><b> expiresInSec : <b>" + new Date(System.currentTimeMillis() + expiresIn * 1000)); 
out.println (“<br>; ;---------------------------request processed------------------------“);     
} catch (Exception e) { 
e.printStackTrace(); 
out.println(“Exception is : “ + e + “; exc messaage is: “ + e.getMessage());
}
} 
public void destroy () {
super.destroy ();
   }
}

Provide oracle.wsm.security.WSIdentityPermission to your client application via WLST :

grantPermission(appStripe=None, codeBaseURL='file:${common.components.home}/modules/oracle.wsm.common/wsm-agent-core.jar',principalClass=None

Connect to the client admin server and run the following WLST to export the client's signing certificate to a file:

svc.exportKeyStoreCertificate(appStripe='owsm', name='keystore', password='', alias='orakey', keypassword='welcome1', type='Certificate',filepath

Configure OAuth server to trust client.
1. Go to OAuth Configuration and modify the client.
2. Trust the client and upload the certificate file generated in client environment.
Invoke client app to get Access Token.
1. Deploy the client app and invoke the URL from browser.
  
  Note:
  You can see the successful response along with the access token from OAuth2 server. This AT can be used to invoke the resource deployed on the resource server.

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

For more information, see 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.

10.7.4 Enabling User Assertion by Username/Password in OAuth Policy

Each application is assigned a different generic user as there are multiple applications in a Weblogic Domain.

User assertion using unique username/password is enabled by attaching OAuth policies. Two new policies attached for user assertion are as follows:

http_oauth2_token_with_resource_owner_creds_client_policy
http_oauth2_token_with_resource_owner_creds_over_ssl_client_policy.

The client side OAuth policies - grant_type (default value/absence of it will mean grant_type is client_credentials) includes a new config override.

Add grant_type in the override prop. In these policies the grant_type will be set to password.

Note:

If grant_type is password then username and password will be set in the header of the request to the oauth server using the csf-key.

The OAuth policies do the following:

Assign Resource owner password credential with Basic auth flow
Assign Resource owner password credential with JWT bearer flow

The OAuth policies are attached in the following ways:

Attaching Policies and Providing Config Overrides Programmatically
Attaching OAuth config policies from WLST
Attaching OAuth config policies from EM

Note:

The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.

10.7.5 About OAuth Based Anonymous User Authentication

OWSM supports OAuth based anonymous user access.

In order to access the REST APIs (anonymous or non-anonymous), the calls are made, such that an OAuth ClientId and Client Secret are generated. The anonymous users do not use their user credentials to get access to the REST endpoints.The anonymous APIs allow the applications to invoke the endpoints without requiring user authentication, while non-anonymous APIs require user authentication.

Note:

Anonymous APIs are not open to the public but they require an access token in the Authorization header.

In order to support OAuth based anonymous user access, OWSM has a policy property enable_anonymous_client_at. This property establishes the subject as anonymous, even if the user does not exist in the Identity cloud service, when the client_id and the sub values in the token are the same.

This configure override, enable_anonymous_client_at uses client access token from identity cloud service, as anonymous token if the value is true. The default value of the policy is false and it is enabled by, setting this configuration to true. In scenarios where, the configuration is set to true, OWSM authenticates the user anonymously to create an anonymous subject after the identity cloud service client access token has been validated.

The following OWSM policies have the enable_anonymous_client_at property:

oracle/http_jwt_token_over_ssl_service_policy
oracle/http_jwt_token_service_policy 
oracle/http_oam_token_service_policy 
oracle/multi_token_cg_sso_over_ssl_rest_service_policy 
oracle/multi_token_cg_sso_over_ssl_rest_service_policy 
oracle/multi_token_cg_sso_rest_service_policy 
oracle/multi_token_cg_sso_rest_service_policy 
oracle/multi_token_over_ssl_rest_service_policy 
oracle/multi_token_over_ssl_rest_service_policy 
oracle/multi_token_rest_service_policy 
oracle/multi_token_rest_service_policy 
oracle/multi_token_sso_over_ssl_rest_service_policy 
oracle/multi_token_sso_over_ssl_rest_service_policy 
oracle/multi_token_sso_rest_service_policy 
oracle/multi_token_sso_rest_service_policy

The JWT and OAM assertions inside the multi_token policies have enable_anonymous_client_at config override.

The following is an example of attaching the policy and changing configuration override using WLST:

beginWSMSesion()
createWSMPolicySet('rest-resource-policy-set', 'rest-resource','Domain("*")')
attachWSMPolicy('oracle/multi_token_rest_service_policy')
commitWSMSession()
 
beginWSMSession()
selectWSMPolicySet('rest-resource-policy-set')
setPolicySetPolicyOverride('oracle/multi_token_rest_service_policy', 'enable_anonymous_client_at', 'true')
commitWSMSession()

10.7.6 About Multitenant Support for OAuth Token Validation

OWSM validates the OAuth token, once the valid trust certificates are imported into the trust store.

In scenarios with multiple tenant support, OAuth token is validated, either by importing the trust certificates of all tenants (created or yet to be created) into the trust store or by using discovery feature.

The discovery feature helps OWSM to fetch the required trust certificates from Identity Cloud Service (IDCS) and use that to validate the OAuth tokens. The discovery feature is used to setup trust at global level using REST API, where all tenant will use the global information to set up trust.

The global discovery information in case of IDCS , does not have any tenant information and it is used to access the JWK/Discovery information for any tenant.

Note:

This requirement to support discovery feature for multiple tenants in a single instance environment is different from layered multitenant scenario where each tenant has its own database.

10.7.7 About Proxy Configuration for Outbound OAuth 2.0 on the Client Application

You can configure the proxy for OAuth 2.0 server token endpoints on the client application using the WLST command or REST API. To avoid network errors while using the OAuth 2.0 with Oracle Web Services Manager, you must enable proxy for the OAuth 2.0 server token endpoints that requires proxy configuration.

Topics

10.7.7.1 Enabling Proxy for OAuth2 Server Token Endpoints

Use the WLST commands or REST API to enable proxy for a single or multiple OAuth 2.0 Server endpoints.

Topics

10.7.7.1.1 Enabling Proxy Using WLST

You can enable proxy for a single or multiple OAuth 2.0 Server endpoints (token.uri) using the WLST commands.

Complete the following procedure to enable a proxy for OAuth 2.0 server token endpoints:

Connect to the running instance of WebLogic Server as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

Configures proxy for a URL:

setWSMTokenIssuerTrustProxy(issuer,identifier, proxyHost,proxyPort)

Argument	Value
`issuer`	Specify `None`.
`identifier`	Identifier which represents the URL. The following URL formats are supported: Absolute URI. For example: `https://accounts.example.com/o/oauth2/token` Base URL ending with the * (wildcard). For example, `https://accounts.example.com/`. Specify (wildcard) to enable proxy for all OAuth2 server token endpoints in a client application. For example, `"*"`.
`proxyHost`	Proxy host.
`proxyPort`	Proxy port.

See setWSMTokenIssuerTrustProxy in WLST Command Reference for Infrastructure Components.

The following examples set proxy for a specific and multiple token endpoints.

For a Specific Token Endpoint on the Client Application

setWSMTokenIssuerTrustProxy(None,"https://accounts.example.com/o/oauth2/token","www.proxy.com","80")

For all Token Endpoints on the Client Application

setWSMTokenIssuerTrustProxy(None,"*","www.proxy.com","80")

10.7.7.1.2 Enabling Proxy Using REST API

You can use the token issuer trust REST API to enable a proxy for a OAuth 2.0 server token endpoint.

Complete the following procedure to enable a proxy for a OAuth 2.0 server token endpoint (token.uri):

Use the GET method to view the existing token attribute rule for the OAuth 2.0 server token endpoint (token.uri).

curl -i -X GET -u username:password http://myhost:7001/wsm-pmrest/v2/trust/{trustdocumentName}attributerule?issuername=name&identifier=(identifier)

The following table lists the query parameters:

Name	Description
`issuername`	Issuer name of the token attribute rule. Specify `NONE`.
`identifier`	Identifier which represents the encoded URL. For example: `https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken`

Example

curl -i -X POST -u Smith:Password -H Content-type:application/json http://myhost:7001/wsm-pmrest/v2/trust/trustdocName/attributerule?identifier=(https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken)

The following shows the example of the response body.

[
  {
    "identifier": "https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken"
  }
]

If attribute rule for the OAuth 2.0 server token endpoint (token.uri) does not exist then you must create an attribute rule using the POST method.

curl -i -X POST -u username:password http://host:port/wsm-pmrest/v2/trust/{trustdocumentName}/attributerule

Example

curl -i -X POST -u Smith:Password -d @reset.json -H Content-type:application/json http://myhost:7001/wsm-pmrest/v2/trust/trustdocName/attributerule/NONE/https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken

The following shows an example of the response indicating the request succeeded.

{
  "STATUSCODE": "20101",
  "MESSAGE": "TokenAttributeRule \"[https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken, issuername:null]\" are successfully created."
}

The following shows the example of the response body.

[
  {
    "identifier": "https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken",
  }
]

Use the POST method to add proxy for the OAuth 2.0 server token endpoint (token.uri) attribute rules.

curl -i -X POST -u username:password http://host:port/wsm-pmrest/v2/trust/{trustdocumentName}/attributerule/{IssuerName}/{Identifier}/proxy

The following table lists the query parameters:

Name	Description
`issuername`	Issuer name of the token attribute rule. Specify `NONE`.
`identifier`	Identifier which represents the Encoded URL. For example: `https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken`

Example

curl -i -X POST -u Smith:Password -d @reset.json -H Content-type:application/json http://myhost:7001/wsm-pmrest/v2/trust/trustdocName/attributerule/NONE/http%3A%2F%2Fmyexample.com%2F%2A/proxy

The following shows an example of the response indicating the request succeeded.

{
  "STATUSCODE": "20171",
  "MESSAGE": "Proxy for TokenAttributeRule for issuer \"NONE\" and KeyIdentifier \"https%3A%2F%2Faccounts.example.com%2Fo%2Foauth2%2Ftoken\" is successfully created."
}

The following shows an example of the request body.

{
  "proxyhost": "myHostName",
  "proxyport": "1234"
}

10.7.7.2 Managing the Proxy Server Exclusion Lists

If the proxy is enabled for all the token endpoints on the client application then you can override the proxy for specific token endpoints by creating a proxy exclusion list. You can create a proxy exclude lists using either WLST or REST API.

Topics

10.7.7.2.1 Managing Proxy Exclusion List Using WLST

Use the WLST commands to add, view, and delete a proxy exclusion list. To manage the proxy exclusion list, you must set the proxy.exclusion.list configuration property in the Agent category.

Adding a Proxy Exclusion List

To add the proxy exclusion list:

Connect to the running instance of the server in the domain for which you want to view the configuration as described in "Accessing the Web Services Custom WLST Commands" in Administering Web Services.

Use the setWSMConfiguration command and to add the proxy exclusion list.

setWSMConfiguration (context,category,name,[group=None],[values=None])

Argument	Definition
`context`	Specify `none`.
`category`	Specify `Agent`.
`name`	Specify `proxy.exclusion.list`.
`group`	Specify `none`.
`values`	The array of values. For example, `['url1','url2']`.

See setWSMConfiguration in WLST Command Reference for Infrastructure Components.

Example

setWSMConfiguration (None,Agent,proxy.exclusion.list,None,['url1','url2'])

Viewing the Proxy Exclusion List

Use the displayWSMConfiguration command to display the proxy exclusion list.

displayWSMConfiguration (context,category,name)

See displayWSMConfiguration in WLST Command Reference for Infrastructure Components.

Example

displatWSMConfiguration (None,Agent,proxy.exclusion.list)

Deleting the Proxy Exclusion List

Use the setWSMConfiguration command and specify None for values to delete the proxy exclusion list.

setWSMConfiguration (context,category,name,[group=None],[values=None])

See setWSMConfigurationin WLST Command Reference for Infrastructure Components.

Example

setWSMConfiguration (None,Agent,proxy.exclusion.list,None,None)

10.7.7.2.2 Managing Proxy Exclusion List Using REST API

Use the Configuration REST API to add, view, and delete a proxy exclusion list.

Adding a Proxy Exclusion List

To add the proxy exclusion list:

Specify the headers on the cURL command line:
```
-H Accept:application/json
```

Create a JSON document, confprop.json, to update the configuration properties.

The request body contains the details of the update request:

Attribute	Description	Type
`name`	The name of the property. The property name is system-defined and you cannot edit it.	String
`category`	The category of the property. The category name is system-defined and you cannot edit it	String
`values`	The array of values. For example, `url1`.	Array of string

The following shows an example of the request document. In this example, the category and property names are Agent and proxy.exclusion.list, respectively; the value for the property is url1.

[
  {
    "name": "proxy.exclusion.list",
    "category": "Agent",
    "values": [
      "url1"
    ]
  }
]

Submit a PUT request and pass the JSON document defined in the previous step by running the cURL Command:

curl -i -X PUT -u username:password -d @file.json -H Content-type:application/json http://host:port/wsm-pmrest/v2/configuration

Example

curl -i -X PUT -u Smith:Password -d @reset.json -H Content-type:application/json http://myhost:7001/wsm-pmrest/v2/configuration

The following shows an example of the response indicating the request succeeded.

{
  "STATUSCODE": "20032",
  "MESSAGE": "Configuration \"[proxy.exclusion.list of Agent]\" are successfully updated."
}

Viewing the Proxy Exclusion List

Use the GET method to display the proxy exclusion list.

curl -i -X GET -u username:password -H Content-type:application/json http://host:port/wsm-pmrest/v2/configuration?category={categoryName}&name={propertyName}

Example:

curl -i -X GET -u Smith:Password -H Content-type:application/json http://myhost:7001/wsm-pmrest/v2/configuration/?category=Agent&name=proxy.exclusion.list

The following shows an example of the response body.

[
  {
    "name": "proxy.exclusion.list",
    "category": "Agent",
    "source": "/WLS/base_domain",
    "values": [
      "url1"
    ]
  }
]

Deleting the Proxy Exclusion List

Use the PUT method to delete the proxt exclusion list.

curl -i -X PUT -u username:password -H Content-type:application/json http://host:port/wsm-pmrest/v2/configuration?category={categoryName}&name={propertyName}

Specify null for value to delete the list.

The following shows an example of the response indicating the request succeeded.

{
  "STATUSCODE": "20032",
  "MESSAGE": "Configuration \"[proxy.exclusion.list of Agent]\" are successfully updated."
}

The following shows an example of the response body.

[
  {
    "name": "proxy.exclusion.list",
    "category": "Agent",
    "values": null
  }
]

10.7.8 About Support for OAuth 2.0 Tokens with Application Defined Scopes

OWSM supports OAuth2 tokens with application defined scopes. OWSM provides a framework through which a user can provide custom audience condition evaluation logic.

OWSM discovers these conditions using HK2 discovery and checks for its applicability to the current request and if applicable, the conditions are evaluated.

Note:

Custom Implementation Indicates, whether this audience validation is sufficient or necessary or sufficient and necessary. It also evaluates API response to indicate the following:

If the conditions were evaluated or skipped
If evaluation result was a success or a failure
The Response messages.

Contract Details

IAudienceCondition

package oracle.wsm.security.audience;

import org.jvnet.hk2.annotations.Contract;

@Contract
public interface IAudienceCondition {
    /**
     * A condition can be of one of three types: SUFFICIENT, NECESSARY or SUFFICIENT_AND_NECESSARY. This function
     * is used to determine which type of condition it is
     * @return the type of condition
     */
    public AudienceConditionType getType();
 
 
    /**
     * This evaluates the condition to be successful or not, applying the logic specific to this condition
     * @param audience the audience string coming from token
     * @param context the data as a Map which is needed for condition to be evaluated
     * @return the condition result containing success or failure result
     */
    public IAudienceConditionResult evaluate(String audience, IAudienceContext context);
}

Input Interface

IAudienceContext

package oracle.wsm.security.audience;


public interface IAudienceContext {
    /**
     * This method is used for retrieving the message context used for this request
     * @return the MessageContext
     */
    public IMessageContext getMessageContext();
 
    /**
     * This method is used for retrieving the claims in the incoming JWT token
     * @return the Jwt Claims in the form of Map
     */
    public Map<String, Object> getJwtClaims();

    /**
     * This method is used for retrieving HTTP header from the transport
     * @return the HTTP headers
     */
    public Map<String, String> getHTTPHeaders();
		/**
     * This method is used for retrieving the value of property from the Map
     * @param the property name
     * @return the property value
     */
    public Object getProperty(String propName);
}

Response Interface

IAudienceConditionResult

package oracle.wsm.security.audience;
 
public interface IAudienceConditionResult {
    /**
     * This returns condition status if it was successful or not when the condition was evaluated
     * @return true if condition is successfully enforced
     */
    public boolean isEvaluationSuccessful();
    /**
     * Used by OWSM engine to identify scenarios where condition is not enforced or was not meant to be enforced but evaluate is invoked
     * @return true if condition is present and enforced, false if it is skipped 
     */
     public boolean isConditionPresent();
  
    /**
     * The condition maintains list of messages (error or non error) when condition is evaluated, 
     * which need to be logged by the caller of this method
     * @return list of response messages to be logged by OWSM engine. It can be an error message.
     */
    public List<String> getResposneMessages();
}

10.8 Understanding OWSM integration with 3rd Party Servers

OWSM is integrated with 3rd party servers like Google OAuth2 server and Twitter OAuth server.

This section describes how to enable OWSM integration.

10.8.1 About OWSM Integration with Twitter OAuth server

OWSM is integrated with twitter. Twitter uses OAuth1 to provide authorized access to its API .

The REST APIs provides programmatic access to read and write Twitter data. Author a new Tweet, read author profile and follower data, and more. The REST API identifies Twitter applications and users using OAuth. Responses are available in JSON.

OWSM supports single-user OAuth use case, which requires providing partial support of OAuth 1.0 protocol in OWSM to use OAuth1 type of access token and token secret to secure the request to Twitter API. In this case, we pick up from the point where we are working with an access token to make signed requests for Twitter resources.

OWSM provides new OAuth1 client policy which allows applications to use Twitter API using the statically generated consumer and access tokens. Retrieval of access token is not done by OWSM policy.

To integrate Twitter account with OWSM do the following:

Prerequisites for configuring Twitter account
Configuring Twitter account for integration with OWSM

10.8.1.1 Prerequisites for configuring Twitter account

Twitter currently uses OAuth1 protocol for most of the authentication methods. OAuth2 bearer token is only supported for application-only authentication. We will focus on single-user OAuth use case, which requires providing partial support of OAuth1 protocol in OWSM to use OAuth1 type of access token and token secret to secure the request to Twitter API.

To use OAuth, an application must:

Obtain access tokens to act on behalf of a user account.
Authorize all HTTP requests it sends to Twitter’s APIs using access token.

10.8.1.2 Configuring Twitter account for integration with OWSM

Twitter Account setup

After you obtain the access tokens, you can configure the twitter account. Follow the steps to create and run a rest application which tweets a message (updates status):

Create Twitter user account at https://twitter.com/.
Using this account, go to https://apps.twitter.com.
Click Create New App to create new application. Fill out all details.
Click on the application.
Click on tab Key and Access Tokens.
Generate Consumer Key and Secret, Access token and Secret.
Note down all four keys as you will need them later - Consumer Key, Consumer Secret, Access Token and access Token Secret.

Configure credentials

Create a CSF key which holds the value of consumer key and consumer secret.

For example: updateCred(map="oracle.wsm.security", key="basic.client.oauth1.credentials", user="NMugHF4zz3ywchygNsXHy", password="XhcrhgVzAHWmerW4JN20xLrv3FliwlbIYPqTnbntUyY9wB", desc="Twitter account consumer key")
Create a CSF key which holds the value of access token and access token secret.

For example: updateCred(map="oracle.wsm.security", key="basic.token.oauth1.credentials", user="778014527828787200-3e7LqGPB79ve0Bbo8Z0acvl7op2", password="ZAVO3BsBNxGMsR7kwGeX3efhqQ2psQvcdvuLLCYXb", desc="Twitter account access token")

Configure the truststore

The Twitter SSL certificate needs to be imported into your keystore

Export the twitter SSL certificate into a local file. Let's call it twitter.crt. You can export the SSL certificate using any browser. For example, if you are using Firefox, you can export as follows :
- Go to https://api.twitter.com/1.1/statuses/update.json.
- Click on the SSL certificate icon at the top / Padlock at the bottom.
- Click on the Details Tab
- Chose which certificate you want from the hierarchy [not circled in picture]
- Click Export
Import this certificate into your truststore. For example, if you are using JKS, you will import it as follows:
- keytool -import -keystore client-truststore.jks -storepass changeit -file twitter.crt

Create a RESTful Client using Jdeveloper

In order to test the integration with Twitter OAuth server, we need to create a web application that will invoke one of the Twitter APIs using the OWSM OAuth1 Twitter Client policy. In the sample provided here we are trying to access the Tweet API at https://api.twitter.com/1.1/statuses/update.json URL.

To create the client application do the following:

Start JDeveloper.
Create a new Application and Project.
Right Click on the new Project created above and select New HTTP Servlet. (if it does not show up there, from the New from Gallery menu, select Web Tier, Servlets, and then HTTP Servlet).
Edit this new servlet with the content provided in the code block below.

Twitter REST Client sample code for POST request

Twitter REST Client sample code for GET request
Add required OWSM and JERSEY libraries as needed.
Save the Project and confirm that all imports have been resolved and there are no build issues.
Deploy your web application to the WLS server. Right Click on the project and select Deploy and then webapp. Deploy directly to the Application Server if you have one configured in JDEV, else deploy to a WAR file and manually deploy this WAR file via the WLS console.

Test the webapp from the browser. You should receive Status 200 from the Twitter API along with some other metadata printed on the browser. You can login to your account www.twitter.com and observe the tweet you sent using OWSM policy.

10.8.2 About OWSM Integration with Google OAUTH2 Server

OWSM OAuth2 clients can integrate with Google OAUTH2 server using the Google OAuth2 Client SSL Policy. Google APIs use the OAuth 2.0 protocol for authenticating and authorizing the client application that requires access.

For OWSM, Google OAuth 2.0 supports server-to-server interactions between a server application and Google APIs. This is a 2-legged OAuth2 scenario, where the server application obtains an access token (AT) from the OAuth server by sending a JWT token and then uses the AT to access the Google APIs. For this scenario you need a service account, which is an account that belongs to your application instead of to an individual end user. The client application invokes the Google APIs on behalf of the service account and not the user.

To integrate OWSM OAuth 2.0 client with Google OAUTH2 server, do the following:

10.8.2.1 Creating a Google Project Using the Google API Console

Each client will have unique credentials to access Google OAUTH2 Server. You need to register the client application with the Google API Console to obtain the client credentials such as a client ID and client secret that are known to both Google and your application. Create the Google API Console project and client ID, as described in Google Sign-In for Websites documentation https://developers.google.com/identity/sign-in/web/devconsole-project.

10.8.2.2 Configuring Google Service Account

Create a Google Service Account

You must configure a Google Service account to integrate OWSM client with Google OAUTH2 server.

You must create a Google service account, as described in the Google Identity Platform documentation https://developers.google.com/identity/protocols/OAuth2ServiceAccount#creatinganaccount

Note:

Keep a note of the Private/Public key generated by Google on your machine as it cannot be re-generated if lost.
Keep a note of the password for the private key as it will not be displayed again.

Access Token Request and Response

Client application request Access Token from the Google Authorization server to access Google APIs.

A single access token can grant varying degrees of access to multiple APIs. A variable parameter called scope controls the set of resources and operations that an access token permits. During the access-token request, your application sends one or more values in the scope parameter.

Permission to perform this type of impersonation must be granted before an application can impersonate a user, and is usually handled by a domain administrator. For more information on domain administration, see Managing API client access.

Upon successful verification of client's request by the OAUTH2 server, client extracts the access token from the response obtained and sends the token to the Google API that it needs to access. Access tokens are valid only for the set of operations and resources described in the scope of the token request.

Note:

Handling Access Token Expiration: The access token once obtained will be cached until it expires. When it expires OWSM will automatically obtain another access token and cache it until it expires.

10.8.2.3 Enabling Google API

You must enable the API(s) on the Google Developers Console, under the project created so that the Google OAuth2 server is able to validate the client's request for an Access Token for any given Google API.

Follow the steps below to enable the API(s) which your application needs to access:

Login to the Google Developers Console using the required credentials.
Click on Overview in the Google API Manager page.
Check the Enabled APIs tab and see if the API you want to access is already enabled. If it is not enabled, go to Google APIs tab and search the API you are looking for.
Click on the required API and then click the Enable button on the top.
Go back to the Enabled APIs tab and verify that the newly enabled API shows up in the list.

10.8.2.4 Configuring the Keystore for the Client Application

Before you configure the keystore for the client application, ensure that you have created the Java keystore (JKS) for the OWSM domain. See Generating Private Keys and Creating the Java Keystore.

Follow the steps below to configure the keystore:

Use the keytool utility to import the PKCS#12 keystore (This keystore is obtained after Creating the Google Service Account) into the JKS keystore.
```
keytool -importkeystore -srckeystore <location of the .p12 file>-srcstoretype PKCS12 -destkeystore <OWSM keystore location> -deststoretype JKS
```
Enter the src and dest keystore pwds. (Hint: The src password is the one noted down after creating the Google Service Account and verify that an entry has been added to the keystore , “privatekey”.
Use the keytool -list command to view the contents of the keystore:
```
keytool -keystore <OWSM keystore location> -list
```

Use WLST to import one or more aliases from the keystore using the importKeyStore script at the command line:

[userx@hostname bin]$ ./wlst.sh 

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect("weblogic","password","t3://myhost.example.com:8001")
Connecting to t3://myhost.example.com:8001 with userid weblogic ...
Successfully connected to Admin Server "jrfServer_admin" that belongs to domain "jrfServer_domain".

Warning: An insecure protocol was used to connect to the server. 
To ensure on-the-wire security, the SSL port or Admin port should be used instead.

wls:/jrfServer_domain/serverConfig/> svc = getOpssService(name='KeyStoreService')

wls:/jrfServer_domain/serverConfig/> svc.importKeyStore(appStripe='owsm', name='keystore', password='password', aliases='privatekey', keypasswords='notasecret', type='JKS', permission='true', filepath='<OWSM keystore location>')

Create a new credential, as per the steps mentioned here, say google-service-credential, in the cwallet.sso. The name of the credential will be the service account email ID which is generated after creating the Google Service Account. Password does not matter.

10.8.2.5 Verifying Integration with Google OAuth Endpoints Using JDeveloper

In order to test the integration with Google OAuth2 server, you need to create a web application that will invoke one of the Google APIs using the OWSM OAuth2 Google Client policy to obtain the Access token. In the sample provided here we are trying to access the Google Drive API at :

"https://www.googleapis.com/drive/v2/files" URL.

Follow the steps to create the client application:

Starting Oracle JDeveloper:
1. UNIX Systems:
  - Navigate to the following location on your system: JDEV_HOME/jdeveloper/jdev/bin/
  - Run the following command: ./jdev
2. Windows:
  Start Oracle JDeveloper from the command line by running one of the following commands:
  - JDEV_HOME\jdeveloper\jdeveloper.exe
  - JDEV_HOME\jdeveloper\jdev\bin\jdevw.exe
Create a Custom Application using JDeveloper, as described in How to Create a Custom Application in Oracle Fusion Middleware Developing Applications with Oracle JDeveloper.
Delete the default project that is auto-created for the application.
Creating a New Custom Project:
1. In the Applications window, open the application that will contain the new project.
2. Click the Application Menu icon, and select New Project to open the Projects page of the New Gallery.
3. Under Items, select Custom Project.
4. Click OK.
Generate the HTTP Servlet:
1. In the Applications window, select the project in which you want to create the new servlet.
2. From the main menu, choose File > New > From Gallery > Web Tier > Servlets, or right-click and choose New. The New Gallery opens.
3. In the Items list, double-click HTTP Servlet to launch the Create HTTP Servlet wizard.

Edit this new HTTP servlet with the content provided in the code block below:

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*; 
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.Response; 
import org.glassfish.jersey.client.ClientConfig; 
import oracle.wsm.metadata.feature.AbstractPolicyFeature;
import oracle.wsm.metadata.feature.PolicyReferenceFeature;
import oracle.wsm.metadata.feature.PolicySetFeature;
import oracle.wsm.metadata.feature.PropertyFeature;
import oracle.wsm.security.util.SecurityConstants; 
@WebServlet(name = "TestClient", urlPatterns = { "/testclient" })
public class TestClient extends HttpServlet {
    private static final String CONTENT_TYPE = "text/html; charset=UTF-8"; 
    public void init(ServletConfig config) throws ServletException {
        super.init(config);
    }
   public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType(CONTENT_TYPE);
        PrintWriter out = response.getWriter();
        out.println("<html>");
        out.println("<head><title><TestClient>/title</title></head>");
        out.println("<body>");
        out.println("<p>The servlet has received a GET. This is the reply.</p>");
       Client client = null;
                ClientConfig cc = null;
                try {
                   String BASE_URI = "https://www.googleapis.com/drive/v2/files";
                    PropertyFeature tokenUri = new PropertyFeature(
                        SecurityConstants.ConfigOverride.CO_TOKEN_URI,
                        "https://accounts.google.com/o/oauth2/token");
                     PropertyFeature csfKey = new PropertyFeature(
                        SecurityConstants.ConfigOverride.CO_CSF_KEY,
                       "google-service-credential");
                    PropertyFeature oauth2CsfKey = new PropertyFeature(
                       SecurityConstants.ConfigOverride.CO_OAUTH2_CLIENT_CSF_KEY,
                        "google-service-credential");
                  PropertyFeature signCsfKey = new PropertyFeature(
                        SecurityConstants.ConfigOverride.CO_SIG_CSF_KEY, "privatekey");
                    PropertyFeature scope = new PropertyFeature(
                        SecurityConstants.ConfigOverride.CO_CUSTOM_JWT_CLAIMS,
                        "scope=https://www.googleapis.com/auth/drive");
                    PolicyReferenceFeature[] clientPRF = new PolicyReferenceFeature[] {
                        new PolicyReferenceFeature(
                            "oracle/oauth2_config_client_policy", tokenUri),
                        new PolicyReferenceFeature(
                           "oracle/http_oauth2_token_over_ssl_google_jwt_client_policy",
                            new PropertyFeature[] { csfKey, oauth2CsfKey, signCsfKey, scope }) };
                    cc = new ClientConfig();
                 cc.property(AbstractPolicyFeature.ABSTRACT_POLICY_FEATURE,
                        new PolicySetFeature(clientPRF));
                    client = ClientBuilder.newClient(cc);
                    WebTarget webTarget = client.target(BASE_URI);
                     Response rest_response = webTarget.request("application/json").get(
                       Response.class);
                    int status = rest_response.getStatus();
                   String textEntity = rest_response.readEntity(String.class);
                     out.println("Response status :" + status);
                        out.println("Response from Google Drive API :" + textEntity);
            out.println("</body></html>");
        } finally {
                  client.close();
                  out.close();
              }
    }
}

Add the JAX-RS Jersey 2.x library to the project, as follows:
1. With the project selected in the Applications window, open the Project Properties dialog.
2. Select the Libraries and Classpath node.
3. Click Add Library.
4. Select JAX - RS Jersey 2.x under Extension and click OK.
Add the wsm-policy-core.jar and wsm-secpol.jar files to the project, as follows:
1. With the project selected in the Applications window, open the Project Properties dialog.
2. Select the Libraries and Classpath node.
3. On the Libraries and Classpath page, click Add JAR/Directory.
4. Click browse and to navigate your JDEV home or JDEV install location/oracle_common/module/oracle.wsm.common/wsm - policy - core.jar and Open.
5. Repeat the above step to install the wsm-secpol.jar file.
Save the Project and confirm that all imports have been resolved and there are no build issues.
Deploy the web application using Oracle WebLogic Server, as described in Deploying Applications in Oracle Fusion Middleware Developing Applications with Oracle JDeveloper.

You must add the WSIdentityPermission to the client application (For example, webapp), this allows the client application to act on behalf of the identity presented in the csf-key. Add the permission by running the WLST command, as follows:

grantPermission(appStripe=None, codeBaseURL='file:${common.components.home}/modules/oracle.wsm.agent.common_${jrf.version}/wsm-agent-core.jar',principalClass=None,principalName=None,permClass='oracle.wsm.security.WSIdentityPermission',permTarget='resource=webapp',permActions='assert')

Test the application by running the following URL on the browser http://hostname:port/GoogleOAuthClient/testclient. Verify that you should receive Status 200 from the Google Drive API along with some other metadata printed on the browser.