Table Of Contents
Best Practices For Resource and Subject Modelling
Flat Categorization of Resources
Tree Categorization of Resources
Multidimensional Resource Categorization
Adhoc Resource Group
Rule Based Resource Group
Best Practices For Resource and Subject Modelling
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.
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).
•Number of policy assignments per subject is low (less than 10), independent of the number of resources and subjects.
•Legacy applications that use a flat structure and you need to first apply policy without changing resource structure.
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:
•Resources for which entitlements need to be made using metadata other than name of the resource.
•Applications with different types of resources (for example, an electronic trading application may have three types of resources: trading books, instrument types, and ECNs).
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:
•Portals where a natural hierarchy of resources includes pages with one or more tabs that contain one or more portlets that in turn hold such things as buttons and tables.
•Trade resources that are modeled hierarchically to represent different trade instruments.
•Application objects with entitlements at any level of the object hierarchy.
Resources with the following characteristics indicate conversion to a categorization attribute:
•The presence of one of the resource attributes that may be used for resource categorization on which entitlements can be defined.
•Applications with many resources (more than 100) that can be categorized across a dimension for easier policy management.
•Applications with an inherent hierarchical data model.
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).
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.
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 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 User attributes in the entitlement infrastructure do not contain authentication specific attributes (such as passwords) as authentication is loosely coupled from authorization and entitlement infrastructures.
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:
•User population is limited.
•Application is not amenable to grouping or categorizing users.
•Entitlement for every user is unique and needs to be supported individually.
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:
•A category of users forming a group of users working as a team on specific tasks.
•A collection of users at partner sites to whom delegated administration of group membership is permitted.
•A hierarchical group of users to eliminate direct user to role mappings.
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.
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.
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.
Q. What is the difference between a role and a group?
A. A role is a collection of resource permissions while a group is a collection of users.
Q. When does it make sense to use role-based access control (RBAC)?
A. RBAC should be used when a set of users or subjects need to be given access to a set of resources. If entitlements are to be assigned on an individual basis, user-based entitlements should be used.
Q. Should users be mapped directly to roles?
A. If the users play only one role and the roles do not change very often, you can map users directly to roles.
Q. When does it make sense to use user-to-group and group-to-role mapping?
A. If the users play more than one role, it is easy to group users in a group and then have roles mapped to the groups. When you create a new user and add the user to a group, the user roles are automatically assigned.
Q. What are the situations when a user may be associated with different role sets?
A. By default a user can have a set of roles, but in other cases he will get a different set of roles. One example is the case when a user is trying to impersonate another user, in this case the role set for the user changes based on whom he is impersonating. This different set of roles for the same user can be achieved by making use of role bundles.
Q. When do you manage users and groups outside CEPM instead of inside CEPM?
A. If the users and groups are maintained in a external directory such as an LDAP or Active Directory, you can continue to manage the users and groups outside of CEPM.
Q. Should I create users by application or application group?
A. If users are common across applications and these applications are grouped together in an application group in CEPM, it is right to create users by application group rather than by application. If the users are specific to an application, it is better to create users by application.
Q. Should groups be created by application or application group?
A. If user groups are shared between applications within an application group, you need to create the groups on an application group. If the groups are specific to an application, the groups can be created by application.
Q. Should roles be created by application or application group?
A. If the roles are specific to an application, you must create the roles by the application they are specific to. If the roles are shared across applications, they need to be created by application groups.
Q. How do I decide what is a resource?
A. If an entity needs to be protected from unauthorized access, it qualifies as a resource. Examples are: a document, a report, and a URL.
Q. How granular should the resources be?
A. The granularity of the resource depends on the level at which you want to control access to the resources. For fine-grained entitlements, you can even consider modeling actions on a resource.
Q. When should you use resource attributes?
A. Resource attributes are the actions on a resource. If you need to entitle users based on the action of a resource, you must model actions. For example, if you want to entitle some users to view a report and some others to edit a report, then modeling actions on the resource (report) helps in modeling fine-grained entitlements.
Q. When must I create resource types?
A. You can create resource types if you need to associate metadata with the resource; this metadata may be required in the decision-making process or the application may require it after getting the decision from the entitlements engine.
Q. When must I create actions for resources?
A. If the access control on a resource has to be more fine-grained, creating actions on the resources helps. For example, if you want to allow some users to view a report and some others to view and edit a report, it makes sense to have view and edit actions on the resource.
Q. When do you choose to create a hierarchical resource structure over a flat structure?
A. If you can categorize resources into a set and need to entitle the entire set of resources using a single policy assignment, it helps to model resources hierarchically.
Q. How do I manage a large number of resources?
A. If the number of resources becomes large, determine a way to reduce the number of resources by having a generic resource and adding additional attributes for the generic resource to make use of the attributes in the decision-making process.
Q. How can I group resources?
A. Resource can be grouped based on general grouping considerations. For example, all reports can be grouped under a resource called Reports, which acts as a container for all the reports. Similarly, in case of a portal application, all portlets can be grouped together.
Q. How do I assign permissions to sets of resources?
A. If resources are grouped together it becomes easy to assign policies to the entire set of resources. If a subject needs to be entitled to a set of resources, a policy can be associated with the resource that is a container resource for the set of resources grouped together.
Q. How do you assign permissions to a specific action across multiple resources?
A. Consider this case: you have numerous reports and each of the reports has a view action associated with them. If you need to entitle a user to view all reports, you need to associate policies with each of the actions on all the reports. An easier way to do this would be to have a view action on the parent resource of the reports and associate a single policy with the same view action. This setting will automatically filter down to all the resources with a view action.
Q. How do you decide what attributes should be associated with a resource?
A. The attributes associated with the resources should either be used in the decision process by making use of the attributes in the rules set on a policy or the attribute is used as a secondary criteria to identify a resource or the attribute value is needed by the application as part of the response.
Q. How do you populate the resource tree?
A. The resource tree can be populated by various methods:
•Create it from the user interface.
•Programmatically create it by using APIs.
•Create the resource hierarchy along with policies from an existing hierarchy in CEPM, using the import or export feature. If you can automatically discover the resource hierarchy, you can do that and use the API to create the resources in CEPM.
Q. How do you verify access policies for only resources managed by CEPM?
A. The application that CEPM protects can have various resources that are not protected. In this scenario, it is best to get a list of resources that are protected and call the decision queries for these resources.