Cisco Enterprise Policy Manager User Guide, Release 3.3.2.0 - Cisco Enterprise Policy Manager [Cisco Policy Administration Point]

Table Of Contents

Cisco Enterprise Policy Manager

CEPM Application

Policy Administration Point

Policy Decision Point

Policy Enforcement Point

Architecture

Communication Mechanisms Between the PAP and PDP

Communication Mechanisms Between the PDP and PEP

Cisco Enterprise Policy Manager

This chapter provides an introduction to the Cisco Enterprise Policy Manager (CEPM) and its capabilities in managing the entitlement issues related to your application. This chapter also provides information about the CEPM architecture and its various components.

CEPM Application

The CEPM application consists of the following three components:

•Policy Administration Point (PAP)

•Policy Decision Point (PDP)

•Policy Enforcement Point (PEP)

Policy Administration Point

The PAP provides central administration, management, and monitoring of entitlement policies.

The key capabilities of PAP are:

•Create and configure users, user groups, roles, and resources.

•Import and synchronize users and user groups in external data repositories, such as LDAP-based directory services.

•Create and configure Policy Decision Points (PDPs).

•Check the entitlements for the User/Role/Group/Resource by associating the PDP to an application.

•Refresh the PDP cache.

•Define policies for users, user groups, and roles to provide fine-grained access permissions using complex rules and contexts.

•Create and configure rules that are based on internal attributes and external attributes that exist in external data sources, such as external databases, LDAP directories, or Java classes.

•Facilitate auditing and monitoring of existing entitlements using PAP reports.

Policy Decision Point

The PDP evaluates application-specific authorization policies.

The PDP is deployed in a highly-available configuration, such as a J2EE web-app, and it receives decision queries from the Policy Enforcement Point (PEP) using XACML 2.0.

The key capabilities of PDP are:

•Execution of role-based and rule-based policies.

•Rules can be shared /reused in the PDP within the scope of that application.

•In-memory policy cache for enhancing performance while responding PEP access requests.

•Look-ahead optimizations that can bundle multiple decisions into one response to enforcers (PEPs).

•Integrated monitor in the PAP for centralized visibility and control.

•Support for external data sources (also called Policy Information Points [PIPs]), such as LDAP directories, external databases, Java classes, and webservices.

•Partial support for XACML 2.0.

Policy Enforcement Point

The PEP resides in the Protected Application context. The PEP acts as an agent embedded inside the Protected Application and sends request to the PDP for implementing authorization decisions for the Protected Application's resources.

The key capabilities of the PEP are:

•Integration with PDP using XACML 2.0.

•XACML compliant enforcers that plug into standard J2EE and .NET servers.

•Extensive logging capabilities for auditing purpose.

Architecture

The CEPM has a three-tier logical architecture. Depending on the deployment model and the specific physical architectures of the applications that the CEPM is securing, the CEPM components (PEP, PAP, and PDP) sit at various network tiers (although still following the three-tier architecture between the components).

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 (database schema) is in the data tier. Physically, the architecture can take on many forms to secure applications with varying architectures, which is one of the strengths of the CEPM application.

The following figure illustrates the architecture of the CEPM.

Figure 1-1 Architecture of the CEPM

Some of the highlights of this flexibility pertaining to each CEPM component are as follows:

•The PEP can be placed in any tier to enforce entitlements for applications or application components running in those tiers.

•The PDP, similar to the PEP, can be placed in any tier to resolve entitlements for the applications or application components running in those tiers; though the PDP is typically placed in a separate network tier for security reasons, unless a local (in-process) PDP is required for performance reasons or otherwise (see Communication Mechanisms Between the PDP and PEP).

•The policy cache is an in-memory cache placed in the PDP which stores the policies and the relevant attributes to enhance the performance of the PDP while responding to the PEP access requests. See CEPM Policy Cache Guide for more information.

•The PAP is generally placed in the application tier as a J2EE web application. The PAP can also be run from within the custom applications that may be present in other tiers (see Architecture).

•The entitlement repository is a database where all the entities of the CEPM, such as policies, resources, users, and roles, are permanently stored.

Refer to the CEPM Concept Guide for more information on CEPM architecture.

Communication Mechanisms Between the PAP and PDP

The PAP and PDP components can be deployed in such a way that they can communicate with each other using one of the following two mechanisms:

•Shared mode—In this mode, the PAP and PDP components interact with each other by using common database instance. In this case, if the database instance is down, both components cannot perform their expected operations.

The following figure Shared Model shows the shared mode of communication between the PAP and PDP components.

Figure 1-2 Shared Model

•Non-Shared mode—In this mode, the PAP and PDP components do not share a common database instance and access separate database instances. They still interact with each other using Java Messaging System (JMS) and thus are loosely coupled with each other. This mechanism removes the dependence of both the components on a common database instance.

The following figure Non-Shared Model shows the non-shared mode of communication between the PAP and PDP components.

Figure 1-3 Non-Shared Model

The non-shared mode works as follows:

1. The PAP component uses a database instance, for example, PAP-DB.

2. The PDP components use a different database instance, for example, PDP-DB.

3. The PAP component publishes the event information to the JMS Server in the form of topics.

4. The PDP components subscribe for these topics with the JMS Server.

5. Whenever an event is initiated in the PAP, the PAP stores the event information in the PAP-DB and publishes that information as a topic to the JMS Server.

6. The PDPs receive the topic information from the JMS Server and store it in the PDP-DB.

Refer to the CEPM Installation and Configuration Guide for more information on PAP-PDP DB separation.

Communication Mechanisms Between the PDP and PEP

The PDP and PEP components can be deployed in such a way that they can communicate with each other using one of the two mechanisms as follows:

•In-Process communication—In this method, the PDP is deployed in the same application server as the PEP. In this case, PEPs simply make library calls to the PDP, which eliminates the network latencies. Refer to CEPM In-process PDP Guide for more information.

•Out-Of-Process communication—In this method, the PDP is deployed either in the same application server as the PEP or on a separate application server. In this case, the PEP interacts with the PDP using TCP-based communications protocols, such as SOAP, XACML, or Java RMI.

	Cisco Enterprise Policy Manager User Guide, Release 3.3.2.0
	Cisco Enterprise Policy Manager
Cisco Enterprise Policy Manager User Guide, Release 3.3.2.0 Preface Cisco Enterprise Policy Manager Overview of the PAP Console Login and Home Page Manage Entities Manage Entitlements Auditing and Reporting System Config Delegated Administration App A - Policy Combining Algorithm App B - User Login Auth using SSO App C - OpenSSL	Download this chapter Cisco Enterprise Policy Manager Download the complete book EPMUser.pdf (PDF - 13 MB) Feedback Table Of Contents Cisco Enterprise Policy Manager CEPM Application Policy Administration Point Policy Decision Point Policy Enforcement Point Architecture Communication Mechanisms Between the PAP and PDP Communication Mechanisms Between the PDP and PEP Cisco Enterprise Policy Manager This chapter provides an introduction to the Cisco Enterprise Policy Manager (CEPM) and its capabilities in managing the entitlement issues related to your application. This chapter also provides information about the CEPM architecture and its various components. CEPM Application The CEPM application consists of the following three components: •Policy Administration Point (PAP) •Policy Decision Point (PDP) •Policy Enforcement Point (PEP) Policy Administration Point The PAP provides central administration, management, and monitoring of entitlement policies. The key capabilities of PAP are: •Create and configure users, user groups, roles, and resources. •Import and synchronize users and user groups in external data repositories, such as LDAP-based directory services. •Create and configure Policy Decision Points (PDPs). •Check the entitlements for the User/Role/Group/Resource by associating the PDP to an application. •Refresh the PDP cache. •Define policies for users, user groups, and roles to provide fine-grained access permissions using complex rules and contexts. •Create and configure rules that are based on internal attributes and external attributes that exist in external data sources, such as external databases, LDAP directories, or Java classes. •Facilitate auditing and monitoring of existing entitlements using PAP reports. Policy Decision Point The PDP evaluates application-specific authorization policies. The PDP is deployed in a highly-available configuration, such as a J2EE web-app, and it receives decision queries from the Policy Enforcement Point (PEP) using XACML 2.0. The key capabilities of PDP are: •Execution of role-based and rule-based policies. •Rules can be shared /reused in the PDP within the scope of that application. •In-memory policy cache for enhancing performance while responding PEP access requests. •Look-ahead optimizations that can bundle multiple decisions into one response to enforcers (PEPs). •Integrated monitor in the PAP for centralized visibility and control. •Support for external data sources (also called Policy Information Points [PIPs]), such as LDAP directories, external databases, Java classes, and webservices. •Partial support for XACML 2.0. Policy Enforcement Point The PEP resides in the Protected Application context. The PEP acts as an agent embedded inside the Protected Application and sends request to the PDP for implementing authorization decisions for the Protected Application's resources. The key capabilities of the PEP are: •Integration with PDP using XACML 2.0. •XACML compliant enforcers that plug into standard J2EE and .NET servers. •Extensive logging capabilities for auditing purpose. Architecture The CEPM has a three-tier logical architecture. Depending on the deployment model and the specific physical architectures of the applications that the CEPM is securing, the CEPM components (PEP, PAP, and PDP) sit at various network tiers (although still following the three-tier architecture between the components). 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 (database schema) is in the data tier. Physically, the architecture can take on many forms to secure applications with varying architectures, which is one of the strengths of the CEPM application. The following figure illustrates the architecture of the CEPM. Figure 1-1 Architecture of the CEPM Some of the highlights of this flexibility pertaining to each CEPM component are as follows: •The PEP can be placed in any tier to enforce entitlements for applications or application components running in those tiers. •The PDP, similar to the PEP, can be placed in any tier to resolve entitlements for the applications or application components running in those tiers; though the PDP is typically placed in a separate network tier for security reasons, unless a local (in-process) PDP is required for performance reasons or otherwise (see Communication Mechanisms Between the PDP and PEP). •The policy cache is an in-memory cache placed in the PDP which stores the policies and the relevant attributes to enhance the performance of the PDP while responding to the PEP access requests. See CEPM Policy Cache Guide for more information. •The PAP is generally placed in the application tier as a J2EE web application. The PAP can also be run from within the custom applications that may be present in other tiers (see Architecture). •The entitlement repository is a database where all the entities of the CEPM, such as policies, resources, users, and roles, are permanently stored. Refer to the CEPM Concept Guide for more information on CEPM architecture. Communication Mechanisms Between the PAP and PDP The PAP and PDP components can be deployed in such a way that they can communicate with each other using one of the following two mechanisms: •Shared mode—In this mode, the PAP and PDP components interact with each other by using common database instance. In this case, if the database instance is down, both components cannot perform their expected operations. The following figure Shared Model shows the shared mode of communication between the PAP and PDP components. Figure 1-2 Shared Model •Non-Shared mode—In this mode, the PAP and PDP components do not share a common database instance and access separate database instances. They still interact with each other using Java Messaging System (JMS) and thus are loosely coupled with each other. This mechanism removes the dependence of both the components on a common database instance. The following figure Non-Shared Model shows the non-shared mode of communication between the PAP and PDP components. Figure 1-3 Non-Shared Model The non-shared mode works as follows: 1. The PAP component uses a database instance, for example, PAP-DB. 2. The PDP components use a different database instance, for example, PDP-DB. 3. The PAP component publishes the event information to the JMS Server in the form of topics. 4. The PDP components subscribe for these topics with the JMS Server. 5. Whenever an event is initiated in the PAP, the PAP stores the event information in the PAP-DB and publishes that information as a topic to the JMS Server. 6. The PDPs receive the topic information from the JMS Server and store it in the PDP-DB. Refer to the CEPM Installation and Configuration Guide for more information on PAP-PDP DB separation. Communication Mechanisms Between the PDP and PEP The PDP and PEP components can be deployed in such a way that they can communicate with each other using one of the two mechanisms as follows: •In-Process communication—In this method, the PDP is deployed in the same application server as the PEP. In this case, PEPs simply make library calls to the PDP, which eliminates the network latencies. Refer to CEPM In-process PDP Guide for more information. •Out-Of-Process communication—In this method, the PDP is deployed either in the same application server as the PEP or on a separate application server. In this case, the PEP interacts with the PDP using TCP-based communications protocols, such as SOAP, XACML, or Java RMI.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks