|
|
Oracle Entitlements Server is an entitlements system that supports the centralized definition of complex application entitlements and the distributed runtime enforcement of those entitlements. It allows you to externalize entitlements – remove security decisions from the application. It provides the means to define application resources and application businesses objects, represent those objects in hierarchical relationships, and write policies that describes which users, groups and roles can access those objects.
You can write policies that control access to both application software components as well as arbitrary business objects in the application. Oracle Entitlements Server also includes a security integration framework that provides an easy way to integrate with existing authentication, Web SSO, identity management, and user provisioning systems.
As shown in Figure 3-1, the Oracle Entitlements Server architecture is made up of two major components – the Administration Server and the Security Service Modules (SSMs).
The Administration Server is the Policy Administration Point (PAP). It manages the storage of policy data in the database and the transactional distribution of policies to the SSMs. The user interacts with the Administration Server through two browser-based administration console where roles, policies, and application resources are defined and managed. The information can also be managed programmatically through the Java management APIs or through Web Service calls.
Runtime enforcement in the application container is accomplished through a set of Security Service Modules. The SSMs are the Policy Decision Points (PDPs) and can be deployed in one of two ways:
The SSMs can make use of application context that may be required to make a policy decision. Additionally, the SSMs can integrate with a number of Policy Information Points (PIPs). These PIPs can be user or application directories or databases that contain information that is required to make an access decision. Such information includes user, group, and resource attributes (e.g. user profile information, account balances and limits, etc.). These attributes can then be used in the policies which control access.
Figure 3-2 shows the components of the Administration Server. It provides browser-based consoles where an administrator defines users, groups, roles, the application resources, and the policies that control access to those resources. The Administration Server can be used to delegate administrative functions to other users. It also provides a policy simulation function that allows you to identify the policies that apply to given resources, users, groups, and roles.
The Administration Server is made up of several components. The Business Logic Manager (BLM) interacts with the policy database to control persistence of policy and other data. The BLM supports transactional management operations for creating and modifying users, attributes, roles, and policies. The Policy Distributor manages the process of distributing policy to the Security Service Modules for runtime enforcement. Policy distribution to the SSMs is incremental and transactional. The Policy Loader manages import and export of policy data. Policy can be exported in XACML 2.0 format.
Java and Web Services administration APIs are provided so that you can incorporate security services functionality into your own applications to automate administration. The administrative APIs can also be used to provide integration with user provisioning systems. For example with a provisioning connector, the attributes of a new employee can be pushed to Oracle Entitlements Server. Those attributes will then provide that employee with immediate access to the required set of applications.
A schematic of an SSM is shown in Figure 3-3. The SSMs are the Policy Decisions Points. SSMs can be fully distributed in the container where the application is running or deployed as a central entitlements server. In the distributed deployment model, they plug directly into the application container to intercept requests and enforce access policies. Applications can invoke the security services directly through either the Java or Web Services APIs. All policy decisions are made by the SSM. SSMs get updated policy information through an incremental and transactional policy distribution mechanism that keeps policy sets up to date and consistent between SSMs.
The entitlements server is also an SSM but one which is deployed on a central server rather than distributed to individual machines hosting the applications. In this case, the centralized entitlements server gets an authorization request from the application either as a Web Services call or using the XACML 2.0 request/response protocol. Like the distributed SSMs, the centralized server can integrate with various Policy Information Points to retrieve and cache user or application information used to make policy decisions.
The SSM contains a security framework that provides a set of standard security services including authentication, authorization, role mapping, auditing and credential mapping. Through the integration with various data repositories (PIPs), the SSMs can retrieve data required to make an access decision. Those data may include static user information which is retrieved when the user is authenticated or dynamic entitlements data that is retrieved at the time a policy is being evaluated. The SSM maintains a fully configurable cache to maintain data required for policy evaluation to minimize attribute retrieval calls to the PIP(s).
Managing and enforcing entitlements generally involves three groups of people. Security architects define security policies that will determine a user’s entitlements in the application. Typically the security architect works with the developer to determine which application resources need to be protected. They work together to define role policies and access policies to be enforced at runtime.
Business users manage the data that controls how the policies are evaluated at runtime. They add and delete users for the applications and put those users into groups or assign them to roles. They manage sets of actions (permissions) that can be logically grouped for a particular business function. They assign those sets of actions to users or to roles defined for the application.
Developers building new applications (or retrofitting existing applications) integrate Oracle Entitlements Server with those applications. This can be done in a variety of ways but the objective is to get the security logic out of the application where it can be managed in a single place. This is accomplished by making an authorization call to Oracle Entitlements Server which will then evaluate access control policy and return an access decision. Since a set of security services are also provided, the developer can use Oracle Entitlements Server as the integration platform for other systems like Authentication, Web SSO, and Identity Management.
Policy is written and managed by administrators and security architects. The policy model is very rich and powerful and can be used to implement a variety of access control paradigms, including rule-based, role-based, and label-based access control.
A label-based model lets a policy authorize access when attributes in a resource match attributes in a user or group. For example, “Allow access to customer records only when a customer’s region code matches a call center representative’s assigned region code.” This type of model is very useful when there are descriptive attributes for both resources and users that can be used to develop policies.
With a rules-based model, policies are written as conditional statements using information gathered at runtime. For example, “Branch Managers are permitted access to monthly revenue reports if their organizational level is greater than 5 and senior management has approved the report”. A rules-based model typically leverages a hierarchical set of resources (e.g., monthly revenue reports) and the conditional expression can be of arbitrary complexity.
With a roles based model, policies are assigned to application roles. Users and Groups are then assigned to Roles, thereby gaining access to various resources. The benefit of this approach is that the concept of a Role decouples an individual or group from the actual policies that determine their access rights. This reduces maintenance costs considerably since an individual can change access to resources by simply moving to a new role. It also aligns better with real world use cases since many individuals work in multiple roles, often simultaneously.
The general form of a policy is as follows:
Effect (Role | Action, Resource, Subject) Constraints
This policy format can be read as “Grant, deny, or delegate an action for a given resource to a subject under some set of constraints” where:
Role policy is used to dynamically determine role membership. Role policies are always scoped to a resource or set of resources. Consider the following example role policy:
Grant (//role/BankManagers, //app/AccountReports, everyone) if (JobTitle=BankManager)
In this example, the BankManager role will be granted to everyone for the AccountReports resource in the application, but only if the user’s job title is Bank Manager. Here a user attribute is used in a constraint to further control the conditions under which the role will be granted.
It is also possible to use role policy to affect separation of duties. The second example shows a simple separate of duties policy. This policy will deny the Analyst role to anyone who has the Trader role in the Brokerage application.
Deny (//role/Analyst, //app/Brokerage, //role/Trader)
The last example shows how a policy can be used to delegate a role to someone else. In this case John is going on vacation. His Approver role in the AccountsPayable application will be delegated to the people in his group (the group called JGroup) during his vacation (August 1 – August 10).
Delegate(//role/Approver, //app/AcctsPayable, //grp/JReports, John)
if (date > 08/01/06) and (date < 08/10/06)
Access policy is used to grant or deny actions to resources in the application to specific users, groups, or roles. Access policy is used to control who is allowed to perform specific actions on an application resource. Consider the following access policy.
Grant (view, //app/Reports, //group/UnitManagers) if reportBusUnit=userBusUnit
In this example, the policy grants the view action on the application resource called Reports to everyone in the UnitManagers group, but only if that user belongs to the same business unit as the report. Here the constraint uses an attribute of the user (BusinessUnit) as well as an attribute of the resource (BusinessUnit).
Access policies can operate on logical resources as well as software resources. A custom resource type can have custom actions associated with it. The next example shows how a custom action called transfer for a bank account might be controlled. The action is granted for a particular account if two conditions are true. The user must be in the list of account owners and the requested transfer amount must be less than the limit set for the account. In this case, the list of account owners and the transfer limit are both attributes of the account (the resource).
Grant (transfer, //app/account, everyone) if user IN accountOwners AND
transferRequest <= transferLimit
The last example shows an additional feature of the policy engine. Normally, the policy engine evaluates a set of policies for a particular access decision and returns an authorization decision (grant or deny). Using the Report function, the policy engine will return additional data with the authorization decision. In this case the value of the transferlimit attribute is returned to the application. The application can then use that data for additional processing.
Grant (transfer, //app/account, everyone) if user IN accountOwners AND (Report(transferLimit))
Oracle Enterprise Repository manages the metadata for any type of software asset, from business processes and Web services to applications and components. It maps the relationships and interdependencies that connect these assets to improve impact analysis, promote and optimize reuse, and measure their impact on the bottom line.
Figure 3-4 shows a typical example of Oracle Enterprise Repository and Oracle Entitlements Server working together. When used with Oracle Entitlements Server, Oracle Enterprise Repository can provide policy versioning and workflow for approval and notification of policy updates. A security administrator defines roles, policies, attributes and other data required to enforce a set of entitlements for an application (or set of applications). At any point, the administrator can store that information as an asset in Oracle Enterprise Repository. If the name chosen is the same as the name of an existing policy set in Oracle Enterprise Repository, a new version number is created. Workflow defined in Oracle Enterprise Repository will be enforced whenever a new policy set is created or a new version of an existing policy set is created. That workflow may involve notifications and/or approvals before the new asset (or version) is registered. The administrator can also pull an existing policy set from the repository into the Entitlements Administration Application to be inspected or modified.
A typical use case involves the migration between staging environments. Let’s take the example of going from the development environment to the QA environment. The security administrator exports policy information to Oracle Enterprise Repository. The policy asset in Oracle Enterprise Repository requires approval by a project manager before it is registered. Once it is approved, Oracle Enterprise Repository can issue a set of notifications. The security administrator must then import the policy into Oracle Entitlements Server in the QA environment. That import also requires approval which can then trigger a second set of notifications.
Within the Entitlements Administration Application, administrators define the components of policy definitions and marshall these components into the policies that govern user entitlements. Administrators may manage entitlements data by organization and application.
It is important to note that the Entitlements Administration Application allows for the shared management of entitlements among security specialists, technical administrators, and business managers. For example, a security specialist might devise a policy model that provides role-based access to an application and then turn over to a business manager the job of assigning users to the application’s role. This would shield business administrators from the complexity of writing policy and allow them to concentrate on role assignments pursuant to business needs of the organization.
In previous releases, users of the Entitlements Administration Applicationn maintained all policies in one flat structure. In this release, ‘organization’ and ‘application’ nodes have been added so that policies can be organized and managed under separate applications. The organization node contains all users and groups as well as one or more applications, where the policies securing one application can be managed separately from another. This not only constitutes a useful user interface improvement, it also allows you to set up different application administrators with full rights to manage the policies securing a particular application, but with restricted rights (or no rights at all) on the policies securing other applications.
To assist in the development and ongoing analysis of policy, the Entitlements Administration Application provides policy reports function and a policy simulation module:
|
