Feedback
Table Of Contents
Best Practices For Resource and Subject Modelling
Flat Categorization of Resources
Tree Categorization of Resources
Multidimensional Resource Categorization
Best Practices For Resource and Subject Modelling
Introduction
Policy-based application entitlement ensures that a subject accessing a resource (or invoking an action on a resource) is allowed/denied based on attribute-based rules.
Figure 1-1 Entitlement Policy
In this model, each subject (such as a user), represented by a set of attributes (such as name and role), accessing a resource (such as an application transaction, document, and portal resources), represented by a set of resource attributes (such as document name and document owner), is protected by a policy enforcer that enforces rules referencing subject, resource, message, and other contextual attributes.
Cisco Enterprise Policy Manager (CEPM) is the industry leader in providing comprehensive support for attribute-based, fine-grain access control and entitlement management that can be applied across heterogeneous applications. Effective use of CEPM requires users to model resources, subjects, and policies appropriately. This document describes common resource and subject models that you can apply to leverage the benefits of CEPM features. This document is a general description of best practices for modeling resources, and subjects and does not cover CEPM products or policy modeling. Refer to the CEPM users guide, developers guide, and quick start guides for instructions on policy implementation using CEPM.
Resource Model
A resource is any protected entity whose access needs to be secured by policy. Resources can be as diverse as trades, documents, web components, data records, business units, geographical locations, application objects, and topics in a message-oriented-middleware (such as Java Message Service).
You can secure resources as a whole or by individual actions that can be performed on the resource. For example, if a document is the protected resource on which you can perform read and write actions, then protecting the named action leaves the other actions unprotected. Protecting the entire resource protects all actions that can be performed on the resource even if they are not predefined. By default, resources that do not have an explicit allow policy for a subject are denied access to the resource or action.
Additionally, each resource is associated with a set of metadata (called attributes). These attributes are chosen because they are likely to be relevant in making policy decisions, or because these attribute values can be communicated to the application along with an entitlement decision. A mandatory attribute that you must associate with a resource is the resource name, which is used to reference the target resource in the user interface and APIs.
This section describes common use cases to model resources to address varying use cases.
Flat Categorization of Resources
Resource categorization is the simplest approach to modeling resources. In this model, resources are represented as a collection of named resources. Resource names are unique and resources must be individually entitled. The following figure shows a sample set of document resources modeled in a flat structure.
Figure 1-2 Flat Resource Categorization
Documents 1 through 4 are individually named and must be individually protected. Each of the documents may also be associated with read/write actions that can also be individually entitled. For N resources, M subjects and P actions, the total number of possible entitlements is (NxMxP). In practice, when an allow policy is not assigned to a resource, it is treated as a deny, thus reducing the number of policy assignments to a fraction of the NxMxP that are positive (allow) entitlements to resources/actions.
While this is a constrained model of resources, applications with the following characteristics indicate the use of this simple mode:
•
Limited number of resources (usually less than a few hundred) and limited number of subjects (usually less than a few hundred).
•
•
Typed resources
The previous section describes documents associated with only actions (read/write), and no other metadata besides the document names. In many situations, resources must be associated with additional metadata (or attributes) that are relevant for making access control decisions.
Figure 1-3 Resource type attributes
As depicted in Figure 1-3, each document resource may contain information, such as owner of the document, date of creation, and coverage area of the document. Each of these attribute values may have to be queried at run-time to make a policy decision to allow access to the resource. In general, these attributes can be viewed as secondary keys in policy decisioning. Primary attribute values (especially when these attribute values are hierarchical) are more appropriately modeled in the resource hierarchy. CEPM supports the creation of resource types that associate a set of attribute values and actions with each instance of a resource of this type. Hence a resourcetype of documenttype will contain the three attributes and two actions discussed so far. When document1 is created of type documenttype, the user can associate values with these attributes and can entitle the actions with Document1.
Resources with the following characteristics indicate a need to model resources with attributes:
•
•
Tree Categorization of Resources
Grouping resources together to entitle the group as a unit vastly simplifies policy assignment and management. One of the common ways of categorizing resources is by using a hierarchical tree.
In this model, one of the attributes associated with the resource is chosen as the primary dimension used to categorize resources. This primary attribute is chosen based on the type of application and the access-control decisions likely to be made.
Consider an example where document access is allowed only for analysts based on the analysts' coverage area (such as Healthcare and High-tech). In this case, analysts as a group covering High-tech are allowed access to documents related to High-tech, and individual documents do not have to be entitled explicitly. In this case, one of the document attributes is no longer managed as a secondary attribute, but as a categorization attribute that is used to group documents.
Figure 1-4 Tree Categorization of resources
Modeling resources using this model provides a convenient way to entitle all documents that cover High-tech as a group without having to individually entitle documents. This approach also allows exceptions, where you can individually deny access to select named documents without impacting other documents in the same group. For example, analyst group1 can be allowed access to all High-tech documents by simply associating an allow policy with the categorization attribute-resource "High-tech". Document3 can still be denied to the same group by associating a deny policy with the High-tech:Document3 resource. Also note that, in this example, the categorization attribute (such as "High-tech" and "Healthcare") are themselves resources that can be entitled.
Resources are referenced by a Fully Qualified Name (FQN). The FQN represents the name of the resource, and the resources can be at any level of the resource hierarchy. For example, High-tech documents may be further classified into "Networking" and "Hardware".
Figure 1-5 Resource Levels
Documents may belong to one or more of these resource groups and can be referenced by an FQN such as "High-tech:Networking:Document2" and "High-tech:Hardware:Document2".
Examples of applications whose resources can be modeled hierarchically include:
•
•
•
Resources with the following characteristics indicate conversion to a categorization attribute:
•
•
•
Multidimensional Resource Categorization
In general, more than one resource attribute may need to be modeled in the resource hierarchy. Consider the previous example, in which both the Coverage and ClearanceLevel are attributes by which documents are to be categorized, as represented in Figure 1-6.
Figure 1-6 Multidimensional resource categorization
This table of documents can be represented row-order as shown in the tree structure to the left. A similar column-order could be chosen to represent the documents in a tree form. In either case, policies can be directly associated with the complete table, a selected column or row, an individual cell, or an individual document in each cell. In this case, each document resource has only two additional attributes: Owner and Date, and two actions: Read and Write. These two attributes can be used as secondary attributes during policy resolution by creating rules.
Resources that are not leaf-nodes are categorization resources that can either hold a collection of same-type resources (such as documents) or heterogeneous collection of resources. For homogenous collections, users can choose to also type categorization resources, such as Hardware and Healthcare, as the same type as the individual resources in the collection, so that common policies for actions across the collection of resources can be specified at the collection level, rather than individually.
The resource model in CEPM is rich enough to support any n-dimensional data set with capability to address resources at any level of granularity.
While deciding on the dimensionality of resource categorization, ensure that you do not default to either extreme of a flat (cardinality of 1) or n (all attributes are considered categorization attributes). Only attributes expected to result in grouping of resources for easier management of policies should be converted to categorization attributes and the policies need to query entitlements only by types (for example, get list of all instrument types that can be traded in an ECN).
Resource Groups
In CEPM, while defining entitlements on the resources, the PAP user picks up each single resource and defines policy and subsequent rules on that resource. When the number of resources is high (say in thousands), performing the same operation for every single resource proved to be a tedious and time consuming exercise. To overcome this, the resource group feature offers a more convenient way to define entitlement policies on a collection of resources through a single instance. Resources, of a particular type, can be grouped together to facilitate the ease of managing entitlements to a group of resources. A resource group holds the same resource type as the resources that the group is composed of.
A resource group can be created in two ways—
•
•
The resource group inherits attributes from the resource type that is associated with the group. Additional actions can be created on the resource group as in case of normal resources.
Adhoc Resource Group
An Adhoc creation allows the user to select resources of the same resource type as the resource group to be members of the group. In this case, the group membership of a resource is determined on the basis of the mapping done under the Assign Resources functionality in the PAP UI.
Rule Based Resource Group
A rule based creation of resource group allows the user to specify a complex rule or simple rule that must be evaluated to true to determine the membership of the resources. During runtime, the membership of a Rule Based Resource Group is determined by two conditions. First, the resources must be of the same resource type as specified in the resource group. Second, the resources must satisfy the rules defined on the resource group.
For instance, a simple rule can be defined as -
ResourceType.owner = `John'- where Owner is an attribute of the resource group or resource type.
The simple or complex rules thus defined are shared across the application on PAP.
During runtime, the policy on the resource group is applied to only those resources which are satisfying the rules defined for the rule based resource group that means the resources with key the value pair as "owner" and "John" respectively can participate in the policy evaluation.
Refer to CEPM User Guide for more information on how to create, update and map resources to the resource group.
Subject Model
Subjects are associated with a mandatory subject-identifier attribute used to express policies. Subject identifiers are typically the authenticated identity of users or applications accessing the resource. The default value for this attribute is the resource name.
In addition to subject-identifiers, you can associate other attributes with subjects. Much like resources, subjects are also associated with two types of attributes: One that is used to categorize subjects by group or role, and another set of attributes to describe subjects in custom form.
Users
Users are a common type of subjects, usually representing internal employees or external customers or partners of enterprises. Users are associated with a default set of attributes. The basic user list is a flat list of users that can be either managed natively in the entitlement infrastructure or can be referenced from external user stores.
Note
Users can be imported by application and users can be individually entitled positively (allowed) or negatively (denied) to resources. User-based entitlement is not suitable for all applications. User-based entitlement can turn into a management and administration challenge with a large number of users and resources.
User-based entitlement is indicated for applications with the following characteristics:
•
•
•
Groups
A group is one of the important attributes of a user that is used to categorize users by organization, team, or other organization structure. User groups can be managed in external LDAP, shared, or by application. User groups can be hierarchical. Entitlements by user group, rather than by users, help ease management and is ideal for use with increased number of users.
Figure 1-7 Group Creation
Groups are particularly useful abstraction in managing:
•
•
•
Roles
Roles are a collection of resource permissions that can be associated with subjects. Thus, a user or a user group associated with one role could result in collection of allow and deny permissions across a collection of resources. Much like groups, roles are also hierarchical and are used to categorize users and user groups.
Ensure that you model roles and groups to be independent of the number of users or resources, and creation of user-specific roles should be avoided. Any user-specific exception in entitlement must be modeled as a user-based entitlement on an otherwise role-based entitlement of resources.
When modeled correctly, the number of roles and resources does not change with increasing number of users or partners who use the application. A common example requires multiple partners to be allowed access to application resources, but with each partner managing their own set of user-role mappings. This use case is best modeled by associating partner users with partner-specific user groups, whose membership is managed by the partner. The application owner simply adds the new partner group association to an existing role, making it simple to add new partner teams.
Typed Subjects
Just as resource types support extensible attributes for resources, user types allows users to define attributes important for entitlement to suit application needs. This feature allows subjects to be easily extended beyond users to other things such as applications and devices. Subject attributes can be referenced in policies that determine whether a subject is allowed access to a resource.
Role-bundles
One recurring requirement across applications is the need to allow subjects (or subject groups) to be associated with different permission sets based on context. For example, a user may be assigned a comprehensive set of roles (and hence permissions) when accessing an application from within the enterprise firewall, but may have a limited set of roles (and permissions) when accessing the same application from outside the firewall. This notion of associating different roles with one user applies to situations when the same user participates in multiple teams (for example a "Deal" team) with varying roles in each team.
FAQ
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
•
•
•
Q.
A.
