10 Configuring Authorization

Authorization (also referred to as access control) enables you to determine what operations authenticated clients can access.

This chapter contains the following sections:

Section 10.1, "Overview of Authorization"
Section 10.2, "Determining Which Resources to Protect"
Section 10.3, "Determining Authorization Permissions"
Section 10.4, "Determining the OPSS Resource Name"
Section 10.5, "Configuring the Oracle HTTP Server to Specify the Request Origin"

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 access to the Web service.

For summaries of the authorization policies available in the current release, see "Authorization Policies" in Chapter 3, "Determining Which Predefined Policies to Use." Chapter 18, "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 Chapter 5, "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

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

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