2 The OPSS Authorization Model

This chapter describes the OPSS authorization model and the security objects used in the model. These objects, which a security administrator can manage with Oracle Authorization Policy Manager, are explained in the following sections:

The Basic Security Artifacts
External Roles
The Policy Model

The terms defined in this chapter are used in the Oracle Authorization Policy Manager user-interface and throughout this guide.

2.1 The Basic Security Artifacts

An application stripe is a logical subset of the domain policy store where the application policies are kept. Unless specified otherwise, the application stripe name is derived from the application display name: an application with display name appName(version) has application stripe name appName#vers. An application stripe can be shared by several applications.

The first distinction among security artifacts accessible with Oracle Authorization Policy Manager is between global and application-specific artifacts.

Global artifacts include users, external roles, and system policies and they apply to all application stripes. Even though system policies are stored in the domain policy store, in this release, Oracle Authorization Policy Manager does not support viewing or managing system policies. System policies are instead managed with Fusion Middleware Control, as explained in Oracle Fusion Middleware Application Security Guide.

Application-specific artifacts include the resource catalog, application policies, application roles, and role categories, and they apply to just an application stripe.

2.2 External Roles

An external role is a collection of users and other groups. The term external role is often synonymous with the terms enterprise role or enterprise group, and it is typically implemented as LDAP groups in the identity store. Similar to other kind of roles, external roles can be structured hierarchically.

For details about the role hierarchy and permission inheritance, see Oracle Fusion Middleware Application Security Guide.

Note:

Within Oracle Authorization Policy Manager, external roles (and users) are viewable only; they are typically managed with a different tool, such as Oracle Identity Manager. For details, see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

2.3 The Policy Model

An application policy can be based on an entitlement (combination of resources and actions across multiple resource types) or on a set of selected resources and actions. Figure 2-1 illustrates the logical model of an entitlement-based application policy (The figure does not illustrate that external roles can be hierarchical).

Figure 2-1 Entitlement-Based Application Policy Logical Model

The components and details of an application stripe are explained in the following sections:

Application Role
Principal
The Resource Catalog
Application Policy
Role Categories

2.3.1 Application Role

An application role is a collection of users, groups, and other application roles; it can be hierarchical. Application roles are defined by application policies and not necessarily known to a JavaEE container. Application roles can be many-to-many mapped to external roles. For example, the external group employee (stored in the identity store) can be mapped to the application role helpdesk service request (in one stripe) and to the application role self service HR (in another stripe).

2.3.2 Principal

A principal is the identity to which the authorization in the policy is granted. A principal can be a user, an external role, or an application role. Most frequently, it is an application role.

2.3.3 The Resource Catalog

The resource catalog comprises resource types, resources, actions, and entitlements.

2.3.3.1 Resource Type

A resource type represents the type of a secured artifact. UI artifacts, such as ADF Taskflows, pages, buttons, fields, web services, reports, URLs, and scheduled jobs, are examples of resource types. Essentially, a resource type is a template for creating resources.

A resource type is associated with one Java class (the matcher class) that describes the actions that can be invoked on instances of the resource type. For example, for the resource type ADF Taskflow, the permission class allows Viewing or Customizing task-flows.

The following points apply to the specification of a resource type:

The name is required and case insensitive.
The matcher class name is required and case insensitive. Typically, the matcher class is the provided OPSS class ResoucePermission, although it can be a custom class. If two or more resource types are to share a matcher class, then that class must be either the class ResourcePermission, or a class extending the abstract class AbstractTypedPermission, or a class implementing the class TypePermission and extending the class java.security.Permission. For further details about the matcher class, see Oracle Fusion Middleware Application Security Guide.
The description string is optional and case insensitive.
The display name is optional and case insensitive. Specifying a meaningful display name is recommended since it is displayed in Oracle Authorization Policy Manager, and it provides extra information that helps security administrators identify artifacts.
The list of actions is optional, case sensitive, and can be empty. An empty action list indicates that the actions on instances of the resource type are determined externally and are opaque to Oracle Authorization Policy Manager, that is, that they are not relevant for resources of this type (in which case the resource is treated as a named resource).

For details about creating a resource type, see Section 5.1.2, "Managing Application Resource Types."

An action is tied to a resource type and defines an operation allowed on a resource. The matcher class associated with a resource type typically describes the list of actions for the resource type. The following are some examples of actions on resources:

Get or post, on a URL.
Read, write, copy, edit, or delete, on a file.
Deposit, withdraw, view balance, view history, transfer to savings, or transfer from savings, on a checking bank account.

2.3.3.2 Resource

A resource or resource instance is an instance of a resource type that represents a concrete resource; it defines an application resource that can be secured by a policy, such as URLs, EJBs, JSPs. At runtime, the application passes the resource name to have permissions checked to determine whether a principal is authorized.

A resource requires an associated resource type, and it can exist independent of entitlements. Note the following points about the case sensitivity of the various strings in a resource specification:

The name is required and case sensitive. At runtime, this is the name that the application passes to the have permissions checked to determine whether a user is authorized.
The description is optional and case insensitive.
The display name is required and case insensitive. Specifying a meaningful display name is recommended since it is displayed in Oracle Authorization Policy Manager, and it provides extra information that helps security administrators identify artifacts.

For details about creating a resource, see Section 5.1.3, "Managing Application Resources."

2.3.3.3 Permission and Entitlement

A permission aggregates a class, resources, and, for each resource, a subset of the actions allowed by the type of the resource.

An entitlement or permission set represents a small set of resources and privileges needed to perform a task, that is, it groups related resources, possibly of different types, needed to perform a business function. Entitlements are reusable collections of permissions that can be granted to multiple principals.

For example, the entitlement Maintain Purchase Orders groups the following resources:

Resource Type: ADF Taskflow
Resource: PO Summary
Action: view

Resource Type: ADF Taskflow
Resource: PO Details
Action: view

Resource Type: ADF Taskflow
Resource: Supplier Details
Action: view

Resource Type: Web Service
Resource: SpendingLimitCheckWS
Action: invoke

Resource Type: Workflow
Resource: POApproval
Action: submit

Note the following points about the case sensitivity of the various strings in an entitlement specification:

The name is required and case insensitive.
The description is optional and case insensitive.
The display name is required and case insensitive. Specifying a meaningful display name is recommended since it is displayed in Oracle Authorization Policy Manager, and it provides extra information that helps security administrators identify artifacts.

For details about creating an entitlement, see Section 5.1.4, "Managing Application Entitlements."

2.3.4 Application Policy

An application policy is a functional policy that specifies a set of permissions that an entity (the grantee, a principal or code source) is allowed within an application, such as viewing web pages or modifying reports. That is, it specifies who can do what in an application.

An application policy uses:

Principals as grantees, and must have at least one principal (Note that, in this release of Oracle Authorization Policy Manager, code sources are not allowed as grantees).
Either one or more permissions, or an entitlement, but not both. Policies that use an entitlement are called entitlement-based policies; policies that use one or more permissions are called resource-based policies.

The application policy model is illustrated in Figure 2-1.

Oracle Authorization Policy Manager provides a rich user interface that allows security administrators to query, provision, and manage application policies. For details, see Chapter 4, "Querying Security Artifacts," and Chapter 5, "Managing Security Artifacts."

Note:

Entitlement-based policies correspond closely with business functions. They are recommended in cases in which a business function considers securing a collection of resources; an entitlement can be used in one or more grants.

2.3.5 Role Categories

A role category is a collection of application roles. Role categories allow administrators organizing application roles in arbitrary flat collections. Role categories are not used in policy evaluations at runtime.

Role categories are independent of (and should not be confused with) the role hierarchy, which applies to both application and external roles. For details about the role hierarchy and permission inheritance, see Oracle Fusion Middleware Application Security Guide.

Role category names are case insensitive. For details about creating a role category, see Section 5.1.6, "Managing Application Role Categories."