Topics:
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.
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
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
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
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.
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.
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:
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.
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.
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:
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:
This procedure helps you to create authorization policy to Return Obligations.
To create authorization policy to Return Obligations, follow these steps:
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:
You can configure OES policies for Coarse-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 coarse-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.
Topics:
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 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 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:
You can configure the OES policy for masking.
Topics:
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:
Create a masking policy to Return Obligations by performing the following steps:
You can attach OWSM OES policy.
Topics:
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:
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 |
---|---|
|
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 defined in OES. Value can be static or dynamic that uses ${} notation.
|
|
Resource name defined in OES. Value can be static or dynamic that uses ${} notation.
|
|
Action that will be used during attributes lookup. Can be Value can be static or dynamic that uses ${} notation. |
|
Action that will be used during real authorization or masking. Default values are Value can be static or dynamic that uses ${} notation. |
|
Set value to true to skip lookup phase. Does not apply to masking policy. |
|
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
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:
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:
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.
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
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.
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.
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. |
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.