FeedbackTable Of Contents
Entitlement Management Using CEPM
Centralized Entitlement Administration and Audit Using PAP
Distributed Policy Resolution Using PDP
Externalized Enforcement Using PEP
Three-tier Entitlement Management Model
CEPM for Custom, Home-grown Applications
In-Process and Out-of-Process PDP
Entitlement Repository Deployment Options
Global Multidomain Deployment Model
Assignment of Permissions to Roles
Assignment of Roles to Subjects
Contextual Assignment of Roles
Delegated Self-Administration for Multitenant Applications
Administration-time Extensions
Concepts Guide
Overview
This chapter describes the high-level concepts related to CEPM and describes:
Entitlement Management Using CEPM
Entitlement Management Using CEPM
The Cisco Enterprise Policy Manager (CEPM) is a unique, scalable, enterprise-ready solution for achieving fine-grained distributed entitlement management, resolution, enforcement, and auditing. CEPM is a paradigm shift from traditional, tightly-coupled, and brittle application entitlement systems to a multitiered, loosely coupled, and standards-based entitlement model consisting of:
•
A centralized and/or distributed Policy Administration Point (PAP)
•
•
Figure 1-1 CEPM Distributed Architecture
Centralized Entitlement Administration and Audit Using PAP
The PAP provides centralized administration, management, and monitoring of entitlement policies, by delegating to and integrating with an entitlement repository. The PAP enables disparate and centralized teams to author policies and access the auditing and reporting features.
Distributed Policy Resolution Using PDP
The PDP evaluates application-specific and enterprise authorization policies. The PDP also connects with existing policy information repositories, such as, Lightweight Directory Access Protocol (LDAP) and databases, which are referred to as Policy Information Points (PIPs).
Externalized Enforcement Using PEP
PEPs enforce entitlement policy decisions made by the PDP for applications, frameworks, and resources.
Physical Architecture
This section describes:
Three-tier Entitlement Management Model
In-Process and Out-of-Process PDP
Entitlement Repository Deployment Options
Global Multidomain Deployment Model
Three-tier Entitlement Management Model
CEPM has a three-tier logical architecture as depicted in the following figure. Depending on the deployment model and the specific physical architectures of the applications that CEPM is securing, CEPM components (PEP, PAP, and PDP) sit at various network tiers (although still following the three-tier architecture between the components). This section provides some examples of various CEPM deployment models that relate to the three-tier architecture model of CEPM and the architecture model of the applications being secured.
Figure 1-2 3-Tier Entitlement Management Model
In general, a three-tier model has a presentation tier, an application tier, and a data tier. Logically, the PEP is in the presentation tier, the PAP and PDP are in the application tier, and the entitlement repository is in the data tier. Physically, the architecture can take on many forms to secure applications with varying architectures, which is one of the product's strengths. Each CEPM component exhibits this flexibility:
•
•
•
–
–
–
The PAP, or PAP functionality, can also be run from within custom applications that may run in other tiers. See "Product Architecture and APIs" section for more information on this scenario. The PAP can also be run in any physical or network tier.
•
CEPM for Custom, Home-grown Applications
The combination of PAP, PDP, and PEP provide the most comprehensive solution for externalized policy and role-based entitlement management for custom applications implemented in Java, .NET, or COM.
In this case, the PAP is used to model policies that are persisted in an entitlement repository. PAP communicates policy updates to the appropriate PDP in real time. The PDP uses these updated policies at run time for authorization decisions. The PEP (Java, .NET, and COM) intercepts application requests and queries the PDP for policy decisions. No authorization-related logic is implemented within the application. Policy lifecycle can be managed either via the PAP user interface or by integrating the PAP functionality into custom administration applications using the PAP Simple Object Access Protocol (SOAP) interface.
CEPM for COTS Applications
Figure 1-3 CEPM for COTS Application
Legacy and commercial off-the-shelf (COTS) applications (such as Documentum and CRM systems) may already have entitlements built into the application. In these cases, it is impractical or difficult to completely externalize run-time policy decisions from within the applications. In the case of COTS applications, it may not be possible or necessary to involve the PDP and PEP in run-time policy decisions. Instead, the PAP is used for externalized administration of entitlements, providing greater control and visibility for administrators to author and change policies in real time, while at the same time enhancing auditing and compliance.
In this deployment model, all policy changes are updated, from the PAP in native form to the applications so that the applications can continue to use their native security mechanisms at run time. This update is achieved in CEPM by configuring custom policy handlers at the PAP. These policy handlers convert administration events to application-specific calls or database entries that result in user-, group-, or role-based access control lists or access control rules.
The PAP database acts as a central authoritative repository of entitlement policies that can be queried for audit and review. In addition, the policy lifecycle can be managed via the API and user interface.
CEPM for Hybrid Environments
Figure 1-4 CEPM for Hybrid Environments
You can simultaneously apply the unique features of the entitlement administration capability of CEPM to custom applications protected by PDPs/PEPs and applications that rely on their native security mechanisms. This simultaneous application is achieved by supporting:
•
•
•
•
In-Process and Out-of-Process PDP
Figure 1-5 In-process and Out-of-process PDP
PDPs can either:
•
•
In the out-of-process case, the PEPs interact with the PDPs via TCP-based communications (for example, eXtensible Access Control Markup Language [XACML] or HTTP), while in the in-process case, PEPs simply make library calls that eliminate network latencies. The PAP can be used to centrally manage the policy lifecycle independent of the deployment model chosen for the PDPs. Both in-process and out-of-process PDPs share code and perform similar functions. The out-of-process PDP is deployed as a WAR file in any servlet container, while the in-process PDP is deployed as a jar file along with the PEP jar. For .NET applications, the .NET PEP is implemented natively in C#, while the PDP can be deployed to run in the same CLR instance through third-party .NET-Java bridges.
Entitlement Repository Deployment Options
An entitlement repository holds all the metadata necessary to administer entitlements for an application and to evaluate policies. The entitlement domain is a view into an entitlement repository. The PAP provides a view into the repository and is responsible for persisting all the metadata into the repository. You can choose to work with one of the domains available from within the PAP. In each domain, there are two models for sharing entitlement policies between the PAP and the PDP:
•
Figure 1-6 CEPM Shared Model
•
a.
The entitlement authority or the PAP has its own repository and changes to the entitlement data are stored in this repository. The PAP has prehandlers that are invoked for every action within the PAP. The handlers are configured to publish every action along with the data to a messaging server. Essentially, the handler acts as a publisher of a message with the entitlement data as the payload to the messaging server. The handler does not persist the entitlement data to the repository in cases where the messaging server is not available.
b.
Consistency between the entitlement repositories used by the PAP and PDP is accomplished by having a reliable message delivery between the two repositories by making use of the messaging infrastructure. The PAP also provides a way to synchronize the entitlement data between the two repositories. When PAP and PDP repositories need to be synchronized, the PAP again makes use of the messaging layer to send the entitlement data for synchronization with the PDP repository.
c.
Reliable delivery is achieved by configuring the messaging server to persist the messages. Although the messaging infrastructure guarantees delivery, you can further configure it to persist the messages when the PDP is down. In cases where the PDP is running but the repository (PDP database) is not down, the PDP sends a message back to the publisher to roll back the changes. This action ensures that data consistency in the two repositories.
Caching Model
CEPM components support a sophisticated caching, prefetching, and policy propagation model. Policy changes made via the PAP are communicated to the relevant PDPs (irrespective of a shared repository between the PAP and PDP) as indicated in 1 in CEPM Caching Model.
Figure 1-7 CEPM Caching Model
The PDP keeps track of policy updates in the PDP decision cache with re-evaluated policy decisions, as indicated in 2. The PDP decision cache contains the most recent decisions for resources. It acts as the master, and policy changes are propagated to the PEP caches via a pluggable, reliable, messaging infrastructure (such as JMS or MQ), as indicated in Step 3. An alternative pull-based model enables PEPs to periodically poll the PDP for any change in decisions; any changes in decisions are then updated by the PEP in its local cache. Additionally, the PEP caches can be configured to persist policy decisions in a database or file system.
The net effect of this architecture is that policy changes made in the central PAP result in near-real-time update of decision caches at the PEPs running with the applications in a reliable manner.
Failure Model
CEPM is designed to have no single point of failure. The PAP (that can itself be deployed in a J2EE cluster) is not involved in run-time decision making and hence, even if the PAP (or PAP cluster) goes offline, the run-time decision infrastructure continues without impact.
1.
2.
3.
4.
With the combination of these features, any failure is isolated without system-wide effects that can disrupt application functions.
Global Multidomain Deployment Model
Note
In this deployment option, the PAP is not shared across geographies. Each geography deploys its own instance of the PAP that persists the entitlement data locally. The PDPs connect to the local entitlement repository and hence, do not require direct messaging with the PAP.
Figure 1-8 Global Multidomain Deployment Model
Policy updates performed in one PAP (using the PAP UI or PAP APIs) automatically result in an event that is published to other peer PAPs that are distributed geographically over a highly-available Message Oriented Middleware (MOM) infrastructure. Alternatively, custom persistence layer mechanisms can also be used to automatically persist and replicate data across multiple repositories.
In all thesecases, you can coonfgiure PEPs to fail over to alternate instance of PDPs across geographies. So, in cases where a local clustered deployment of PDPs (out-of-process) is unreachable, the PEPs automatically fail over temporarily to other instances of the PDP. PDPs can be deployed for load-balancing (round robin) within geographies.
Entity Model
Policy-based application entitlement ensures that a subject accessing a resource (or invoking an action on the resource) is allowed or denied based on policies. The CEPM data model reflects this approach and consists of three basic constructs: subjects, resources, and policies. Each of these are typed and hence, extensible enough to describe policies in varied heterogeneous environments.
Figure 1-9 Entity Model
In this model, each subject (such as a user), represented by a set of attributes (such as name and group), accessing an object (such as an application, transaction, document, portal resources, and so on) represented by a set of resource attributes (such as document name and document owner), is protected by policy that encapsulates rules that reference subject, resource, message, and other contextual attributes required for decision resolution.
Figure 1-10 Entities and Entity Attributes
Subjects
Subjects are associated with a mandatory subject-identifier attribute that is used to identify the subject on whose behalf run-time policy decisions are made. Subject identifiers are typically the authenticated identity of a user or application accessing the resource. This authentication is typically done outside of the scope of CEPM.
Figure 1-11 Subject Model
Essentially, subjects have the following characteristics:
•
•
•
•
•
Resources
A resource is any protected entity to which access must be secured by policy. Resources can apply to a diverse set of real-world objects. Resources are typically used to model:
•
•
•
•
•
This list is not exhaustive and there are other examples of resources such as business units, geographical locations, people, and network segments.
Figure 1-12 Resource Model
Resources have the following characteristics:
•
•
•
Resources can be secured as a whole or as individual actions that can be performed on the resource. For example, if a document is the protected resource on which read and write actions can be performed, 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 allowed policy for a subject (either explicitly or via inheritance) are denied access to resource, action, or both.
Policies
Policies in CEPM are rule- and role-based and are flexible enough to handle varying granularities of authorization. A spectrum of policies from simple application-specific, role-based access control or portals, to dynamic, rule-based separation-of-duty policies during collaboration are handled in a consistent and easy-to-use manner. The policy model provides a rich hierarchical model of resources, subjects, obligations and actions in line with standard industry terminologies and authorization models such as role-based access control (RBAC) and XACML.
Targets resources, actions, or subjects are protected by a set of one or more policies (called PolicySets). Conflicts between policies in a PolicySet are resolved via policy-combining algorithms (for example, deny-overrides and permit-overrides). (See Policy-Combining Algorithm.) A policy in turn contains one or more rules that support a rich condition-effect syntax that enables the expression of complex rules in a standards compliant manner. You can find details of the policy language at http://www.oasis-open.org/committees/xacml/.
Figure 1-13 Policy Model
In addition to returning a decision, the entitlement engine returns one or more obligations to the PEP. Obligations allow the PDP to communicate certain requirements or constraints that the PEP should follow while using the decision. For example, an allow decision may be communicated to the PEP, but with the constraint that the PEP is obliged to do such things as log the request or add certain attribute values in the session cache.
Policy-Combining Algorithm
1.
2.
3.
4.
5.
6.
Policy Model
This section describes:
Assignment of Permissions to Roles
Assignment of Roles to Subjects
Contextual Assignment of Roles
Delegated Self-Administration for Multitenant Applications
XACML Policy Model
Policies are normalized into the XACML model in CEPM. A decision query request to the PDP consists of attributes associated with:
•
•
•
•
A response contains one of four decisions:
•
•
•
•
Responses may also include obligations, which are directives from the applicable policies which the PEP is obliged to execute.
Figure 1-14 XACML Policy Model
XACML policies consist of an arbitrary tree of subpolicies. Each tree represents a target, while the leaves of the tree contain a collection of rules. The target is a simple set of criteria (on resources, subjects, actions, or the environment) to determine the applicability of the policy to a request, while the rules contain more complex logic that makes XACML extremely expressive, and therefore able to handle complex policy requirements.
In addition to expressing access-control logic within a single policy, policies can include references to other policies. This abstraction achieves the goal of modularly building complex policies while also providing a mechanism to handle policy conflicts. In effect, a single policy can consist of any number of decentralized, distributed rules, each managed by different organizational groups. A key supporting language feature is the way XACML uses combining algorithms, which define how to take results from multiple rules or policies and derive a single result. As with datatypes and functions, a number of standard combining algorithms are defined (such as first applicable and deny overrides), as well as a standard extension mechanism used to define new algorithms.
Policies depend on access to attribute values associated with things such as subjects and resources. Two mechanisms are used to resolve attribute values within policy logic:
•
•
The PDP can access external attribute values via pluggable data access modules.
You can create policies are created using this two-step process:
1.
2.
A variation to these steps allows you to directly associate rule-based policies for users or groups of users without explicitly defining roles. In either case, the underlying policy resolution logic in CEPM works exactly the same way.
Assignment of Permissions to Roles
In many situations, the result of evaluating policy at run time is an allow or deny decision for a specific subject based on the subjects' membership in a role. In this context, the collection of privileges (positive and negative) associated with a role are modeled in CEPM, resulting in an access-control matrix, Roles and Actions. An access control matrix such as this is helpful in determining (or modeling) permissions on paper before attempting to build the model in CEPM.
Table 1-1 Roles and Actions
Member
X
X
Owner
X
X
X
Submitter
X
Trader
X
X
Admin
X
Super User
X
Hierarchical RBAC
The three common approaches used for hierarchical RBAC are:
a.
b.
c.
CEPM supports the inverted-tree and lattice models.
Note
The inverted-tree model enables higher-level roles to add to privileges that may be granted to lower-level roles. For example, a project lead has all privileges of a production and quality engineer in addition to privileges assigned to project leads. The lattice model is also supported in CEPM via the capability to reference roles while creating a role hierarchy, and support for multiple inheritance.
Figure 1-15 Inverted Tree (b) and Lattice (c) Role Models
Assignment of Roles to Subjects
Subjects can be statically assigned to roles via explicit assignment, or a subjects' association with a role can be determined via dynamic evaluation of rules and policies at run time. CEPM supports both static and dynamic approaches for role assignment. Within CEPM, roles determined via dynamic evaluation of rules and policies at run time are called dynamic roles. Examples of dynamic roles include assigning subjects with the attribute employee to the Employees role, or assigning subjects with an account balance of greater than $100,000 to the Platinum Trader role.
Scoping of Roles
In many situations, the resources or attributes of a resource to which the role grants access must be limited (or scoped). In this case, the resource has certain attribute values, which acts as a means to scope the privileges of a subject. For example, a subject (say Joe) may be associated with a WiresAdministrator role, but only for accounts with the location attribute set to California. Attributes associated with subjects, resources, and roles can be used to scope the role in CEPM. Additionally, CEPM allows users to choose the relevant scope attributes as well as entity attributes that need to be returned to the application for further processing.
Contextual Assignment of Roles
A subject is not provided with a blanket set of privileges. Instead, subjects are assigned a different set of roles in different contexts. For example, Joe may be associated with WiresAdministrator and WiresUser roles during work hours, but may be associated with the WiresUser role after hours. This capability to contextually assign a set of roles to users is accomplished in CEPM by using RoleBundles, which provides a convenient mechanism to assign users to a collection of roles that are assigned in different contexts.
Delegated Administration
Because multiple applications, resources, and groups of subjects are all being managed from the same administration environment, there is a need for delegated administration of these entities. CEPM supports the capability to delegate administration up to an individual resource level, and individual subject-group level, which enables multiple administrator ownership within the same user population and application.
Delegated Self-Administration for Multitenant Applications
In addition to delegated administration of resources and groups, for applications that are hosted in a multitenant model, wherein an application is offered as a service to multiple partners or customers, there is a need to create the notion of a hierarchical delegated context, which allows autonomous delegated control to administrators to create mappings of subjects to roles, and association of privileges to roles. This model supports a default context in which roles and their associated privileges are defined, and allows delegated administrators to inherit / override these default mappings and privileges for their domain is supported in CEPM via the context construct.
Product Architecture and APIs
This section describes:
Administration-time Extensions
Typical IT Stack
CEPM allows externalized policy-based entitlement of resources at various layers in the IT stack. Typical IT Stack depicts four common layers where entitlements are required:
Figure 1-16 Typical IT Stack
The three-tier architecture of CEPM enables codeless protection of resources in all these tiers through agents. These agents intercept messages at the container-level and enforce policies with the PEP. In these cases, developer involvement is minimal (if any) and is largely confined to configuring the appropriate container-specific configuration files.
However, in cases where resources are not container managed, or resources that require protection through code need to make API calls such as "isUserAuthorized()" calls, such APIs for decisions are supported via PDP APIs. Similarly some applications need to make API calls for administration such as to grant or revoke user privileges and query available resources. Such administrative calls are supported via the PAP APIs. PDP and PAP APIs are supported via packages in Java, .NET, and COM-based libraries.
Java PEP
CEPM supports a Java PEP in the form of a .jar file. This library exposes APIs that can be directly invoked from any Java-based application and can be used by container-specific agents to enforce policies at the container level. Refer to the Java documentation for details about the APIs supported. The Java PEP supports Java libraries for both decision and administration APIs.
.NET PEP
.NET-based applications can be entitled using PEP for .NET. The agent is a dynamic-linked-library (DLL) that can be used by any .NET-based application (either a desktop or a web-based application). A COM-wrapped agent is also supported for VB, C++, and other Windows-based applications. As with the Java PEPs, the .NET PEP supports libraries for decision and administration APIs. Refer to CEPM DotNet Agent Guide for detailed instructions on usage and deployment of APIs.
The two packages of interest are:
•
•
Figure 1-17 CEPM Component Flow Diagram
These packages are intended for customization and easier integration of CEPM components in customer deployments. Using the APIs you can:
•
•
•
Administration APIs
PAP APIs help in accessing a broad set of functions that are enabled through the PAP user interface. You can use these APIs to create your custom user interface or to write scripts to create entities such as users, roles, and applications rather than creating them one at a time from the user interface.
The PAP user interface and the SOAP APIs (accessible via the .NET and Java APIs) support various functions, including those relating to:
•
–
–
–
–
•
–
–
–
–
–
–
•
–
–
–
–
–
–
–
–
•
–
–
–
•
–
–
–
•
–
–
–
–
•
–
–
–
–
Refer to the Javadoc for more info on various methods.
Decision APIs
The PEP Interface provides methods if a user is entitled to access a given resource or action in the PEP. This interface also provides two utility methods that return a list of permissible resources for a user and a list of permissible actions for a resource.
A non-exhaustive list of APIs supported by the PDP APIs include:
•
•
•
•
•
Extensibility Interfaces
In addition to PAP and PDP APIs, CEPM allows you to customize various aspects of the policy infrastructure through extensible APIs. These APIs can be broadly classified into:
1.
2.
Figure 1-18 Extensibility Interface
Administration-time Extensions
Administration-time extensions allow administrators to extend the functionality of the PAP. Using PAP extensions, you can
•
•
Prehook
CEPM supports the notion of prehooks that can be used to initiate a workflow from within the administration console or the PAP. In addition to workflows, you can use prehooks as a means to allow PAP for policy authoring and review even when policy decisions and enforcement happen outside the scope of a PDP and PEP. All administrative actions are configureably intercepted by the prehook handlers, and appropriate actions can be triggered (including writing out policies in legacy or native forms). The interface for prehook is shown here:
public interface IHandler {public void init(Properties props);public void handle(Object policy,ActionEvent action)throws HandlerException;public void rollBack(Object obj[] , ActionEvent action[]);public void rollBack(Object obj , ActionEvent action);}The IHandler interface also exposes a rollback method that can be implemented to handle error conditions that require rollback previously handled policy events.
Importing/Exporting Policies
CEPM allows import and export of policies using XML-based files via APIs and the PAP user interface. Additional utilities have been built to directly convert MS Excel spreadsheet-based entitlement information into policies within CEPM.
Decision-time Extensions
Decision-time extensions allow you to extend the PDP functionality by plugging in custom attribute sources or custom listener frameworks.
Custom Attribute Sources
Attribute sources are used to get additional information from an external source that is used in policy evaluation. CEPM supports the following attribute sources out of the box:
•
•
•
•
To add a custom attribute source:
1.
To evaluate the attribute and allow the PDP to retrieve the attribute values for use in the decision process, implement the following interface:
public interface IAttributeEvaluator{Public Object evaluate(IAttribute iAttribute,IPIPMetaData pipMetaData,IXacmlContext xacml,IRule rule,Rules rules)throws Exception;}This interface needs to be implemented for the PDP to get the attribute values.
Custom Listener Framework
The Custom Listener Framework provides a way to add additional transport protocols for communication between the PEP and PDP. By default, SOAP over HTTP, XACML over HTTP, and RMI are supported out of the box. If you need to add a protocol that is not supported out of the box, implement the following interface:
public interface ITransportAdaptor{public void init(PdpObject pdpObj);public Object send(XacmlRequest request)throws Exception;public PdpObject getPdpObject();}Custom Authentication
The administration console (the PAP) and the decision engine (the PDP) authenticate users before providing services. CEPM by default supports authentication against its entitlement repository or against an LDAP. To plug in custom authentication providers, such as JAAS, implement the following interfaces:
public interface IAuthenticator {public boolean authenticate(String username, String password);public List getRoles(String username);public boolean isSuperUser(String username) ;}public interface IAuthProvider{public IAuthenticator getAuthenticator(Properties props) throws Exception;public IAuthenticator getAuthenticator() throws Exception;}
