CEPM User Guide - System Config [Cisco Policy Administration Point]

Table Of Contents

System Config

System Config Selection

Application Groups

Adding an Application Group

Deleting an Application Group

Viewing Applications

Adding an Application Attribute Source

Add User Attribute Source

Applications

Adding a New Application

Editing an Application

Deleting an Application

Viewing PDPs

Viewing Resources

Adding Attribute Source Information

Downloading an Agent Configuration

Begin Policy Lookup

Update Policy Lookup from the PAP UI

Update Policy Lookup using DB Jobs

Update Policy Lookup via triggers

Policy Decision Points

Adding PDPs

Editing PDPs

Deleting a PDP

Refreshing the PDP Cache

Viewing Applications

Viewing or Setting the Log Level

Server Status

Context

Application Group Types

Application Types

External Attribute Sources

User Attribute Sources

Creating a User Attribute Source

Update User Attribute Source

Application Attribute Source

Application Attribute Source of Database Type

Adding Attributes to the DB Attribute Source

Using DB Attribute in Advanced Policy Configuration

Using DB Attribute While Creating Typed Attributes

Application Attribute Source of LDAP Type

Adding Attributes to the LDAP attribute source

Application Attribute Source of Java Type

Adding Attributes to the Java Attribute Source

Application Attribute Source of Web Service Type

Adding Attributes to the Web Service Attribute Source

List Repositories

System Config

As a rule of thumb for implementing CEPM to protect the resources, there is a need to evolve a common resource hierarchy by identifying and prioritizing resources. In a wider sense, a resource can be an application group, an application, a resource under an application, or a child resource. The CEPM terminology limits the usage of resource to a "resource created under an application" only.

The System Config tab provides a platform for the authorized PAP user to create an application group, its applications, policy decision point, and external Attribute Sources, such as user attribute sources and application attribute sources. Any authorized user can administer the repository by configuring the CEPM agents (Policy Enforcement Points [PEPs]) and connect each of them to the specified PDPs.

System Config Selection

This section explains the various operations that you can perform on the System Config tab in the PAP administration console.

•Manage application groups—Create, update, and delete application groups. Add application attribute Sources and user attribute sources to application groups.

•Manage applications—Create, update, and delete applications. Add application attribute sources and user attribute sources to applications. Download PEP agent configurations. View associated PDPs and resources.

•Manage PDPs—Create, update, and delete PDPs. Refresh PDP cache, set log level, and display PDP server status.

•Manage contexts—Create, update, and delete contexts.

•Manage external attribute sources—Create, update, and delete user attribute sources and application attribute sources and make use of your own encryption schemes.

•Manage repositories—Create, update, and delete repositories (domains).

Application Groups

An application group is a suite of applications that perform different operations to achieve a common output. For example, a banking application has several applications put under one umbrella, such as retail banking, loans, and insurance. Each division is a separate application installed in a distributed environment across various geographical locations. The application group has a set of entities, such as users, roles, and groups that have a few other relational entities, such as SoD roles and Dynamic roles. Once created, these entities are the subjects for entitlement defined under the same application group across all applications and resources created within it. Contrary to this, if any such entities are created at the Global level (Global user, Global group, Global role, and so on), the utilities can be extended across all applications groups created within the repository.

In this way, an organization can have one or more application groups, which are again a part of repository, which covers the whole resource hierarchy under one umbrella. The list of application groups that constitute the selected repository is displayed in the home page of System Config. When you click the System Config tab, the Application Groups page is displayed, which contains a table listing all existing application groups owned by the logged in user along with the details. You can perform following operations from the application groups:

•Add application group

•Edit application group

•Delete application group

•View applications

•Add application attribute sources

•Add user attributes sources

Adding an Application Group

To create a new application group, you must:

Step 1 On the Application Groups page, click Add.

The Create Application Group page.

Figure 7-1 Create Application Group

Step 2 Enter the new application name and a brief description in the respective fields and click Save.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

Step 3 Select the application group type from the drop-down menu. By default it is set to Default. For details about application group types, refer to Application Group Types. If you select Default as the application group type, there is no need to click Go because it is meant for showing the attributes created under the selected attribute type. You can also create new application group type from this page.

The new application group is included in the list of application groups.

Deleting an Application Group

To delete an application group, click Delete next to that application group. You are prompted to confirm the deletion. Click Yes to delete the selected group, or click No to cancel the action.

Viewing Applications

The View Application button is used to view all the applications that constitute the selected application group.

Figure 7-2 View Application

This page is the same as the List of Applications page. The only difference you can observe is the contents of the List Applications table. In this table, only the applications that belong to the selected application group are listed. All the application-related functions are explained in this chapter.

Adding an Application Attribute Source

An application attribute source is a collection of application metadata used by the PDP while evaluating policies for a specified application. For more details about application attribute sources, refer to Application Attribute Source.

In the Application Group page, after you select an application group you can view all the existing attribute sources. Here you can add an application attribute source created for that application group by clicking Add Application Attribute Source. The Attribute Source Information page is displayed.

Figure 7-3 Application Attribute Sources

This page lists all attribute sources or PIPs that belong to the selected application group. Entitlement Repository is a default attribute source created during PAP installation along with a set of predefined attributes. Other attribute sources shown on this page are created under the corresponding application group.

From this page, you can add new PIP to the application group by clicking the add attribute source button. The process of creating new application attribute sources has been explained in Application Attribute Source.

Add User Attribute Source

A user attribute source is a collection of user metadata stored in an external source, such as LDAP and AD. This information is tagged with a rule created on a policy and is used by the PDP while evaluating policies for the user created on the specified resource. For more details about user attribute sources, refer to User Attribute Sources.

In the Application Group page, after selecting an application group, you can view all the existing user attribute sources. You can add a new attribute source for that application group by clicking Add User attribute source.

Figure 7-4 Add User Attribute Source

This page lists all the user attribute sources that belong to the selected application group.

From this page, you can add new source to the application group by clicking Add. The process of creating a new user attribute sources has been explained in User Attribute Sources.

Applications

Applications are represented as a collection of named resources and actions. An application essentially consists of resources, child resources, and actions. In general the following details are provided in the List Applications table.

Figure 7-5 Applications Home Page

Application owner column displays the owner of the application, that is, the username of the user who created this application group. The Application Group Name column displays the name of the application group under which this application has been created. Other than this, a set of action buttons are added automatically to each applications to carry on different activities, such as:

•Begin Policy Lookup—Refer to Begin Policy Lookup for more information.

•Edit—Enables the user to do necessary modification of application description at any moment.

•Delete—Removes the selected application from the list of applications.

•View PDP— Lists all the PDPs associated with the corresponding application.

•View Resources—Displays all resources and their child resources (if any) that belong to the selected application.

•Add application attribute source—Lists the policy information points or attribute sources associated with a particular application group.

•Add user attribute sources—Lists existing LDAP associated with the application.

•Download Agent Config—Facilitates the user to download the pep_config.xml file of the selected application.

Adding a New Application

To add a new application, you must:

Step 1 Click Add New Application.

The Create Application page is displayed.

Figure 7-6 Create Application

Step 2 Enter the appropriate information in the following fields:

•Application Name—Enter the name of the new application.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

•Description—Enter a brief description of the application.

•Application Group Name—Select the application group name from the drop-down menu.

The drop-down list contains existing application groups. The new application must be included in any of the existing groups.

•Contact Info—Enter the contact information, for example, URL.

•Application Server—Enter the application server in which the new application is running.

•Application Status—An application can be either in Active or Inactive state. Both states are applicable during evaluation of policies by the concerned PDP. While you can make use of the application in the PAP console irrespective of the states selected, the PDP returns "not applicable" if the application status is set to Inactive. It is important to note that any resource and its child resources and actions created under an inactive application become inactive until and unless anything to the contrary is defined.

•Enable Delegation—If you check this option while creating or updating an application, the selected application is available for Copy Entitlement, which allows you to entitle all the policies of a PEP user created on this application and its resources to other PEP users. For more information on how to copy entitlements, see "Copy Entitlements" section on page 4-18.

•Enable Policy Lookup—Check the Enable Policy lookup check box to enable storage of policy data under this newly created application in the Policy lookup table in the CEPM database. Refer to Begin Policy Lookup for more information on policy lookup.

•Enable Xacml Logs—Select the Enable Xacml logs box to enable runtime log generation for the new application. If you uncheck this, you cannot view the runtime application logs in the server side and in the PAP console as well.

This check box relates to the setting of <xacml-log> in the pdp_config.xml file. The PDP component has the option to log the Xacml requests coming from the PEP and the Xacml responses sent to the PEP in a database that is configured in this pdp_config.xml/<xacml-log> tag.The following table describes the xacml-log enable attribute where,

–Label refers to the UI label (that is Enable Xacml Logs)

–Value refers to the pdp_config.xml/<xacml-log> tag value of the XACML logs.

describes the labels and values

Table 7-1 Labels with XACML logs

Label

Value

Description

False

False

No logging will be done even if logging is enabled from PAP

False

True

Xacml request/response will not be logged, though the Runtime logs will be based on the Application property being enabled

True

False

No logging will be done even if logging is enabled from PAP

True

True

Both runtime logs as well as Xacml request/response will be logged.

•Enable Virtual Resources: Enabling virtual resources refers to giving decisions for a virtual resource (not present in the database) on the basis of the permission granted on its parent resource.

For example, an application called 'Prime Portal' (under 'Prime group') has a resource called 'View Reports'. If you have selected 'Enable virtual resources' for 'Prime portal', and if an access request for 'Prime group:Prime portal:View Report:Report7' (where there is no resource with the name Report7) hits the PDP, the PDP gives the decision on Report7 on the basis of the permission defined on 'View Reports' regardless of the fact that the resource called Report7 does not exist in the database.

In the above scenario, if `Enable Virtual Resources' is not selected for Prime portal, the decision for the above access request would be 'Not Applicable'.

•Combine with inherited policies: If you check this field, the requested resource inherits its policies from:

–Itself

–Its parents

–Application.

For example, consider a resource called Res2 under resource Prime group:Prime portal:Res1. Resource Res1 is having Allow:Internal Dev policy and resource Res2 is having Allow: Internal Dev Tokyo policy and the application Prime portal is having Allow:Internal Dev London policy.

If the "Combine with inherited policies" field is enabled for the application and the request for Prime group:Prime portal:Res1:Res2 is sent, then it gets all the three policies: Internal Dev Tokyo (itself), Internal Dev (its parent), and Internal Dev London (application policy). The PDP gives the decision after applying the Policy Combining Algorithm.

•Application Type: Select the application type from the drop-down list. If you do not select the application type, Default is considered the application type.

•Policy Decision Point Names: Select the application server to be associated with the new application. In the runtime process, when the PEP sends a request, it reaches the selected PDP, and the PDP responds to the request by querying the concerned database and gives the appropriate decision. You can select multiple PDPs for a single application. This helps the PDP decision-making process to remain uninterrupted even in case one of the PDPs shut down.

In the Agent-PDP section, the PDP field contains all existing PDPs registered under the application. While creating a new application, select PDPs to be associated with it.

Step 3 Click Create to add the new application to the existing list of applications.

The List of Applications page is displayed where you can view the new application in the table.

Editing an Application

Editing the application name is not allowed in CEPM. When you want to associate additional PDPs with your application along with the existing PDPs, you can do so by editing an application. When you add or delete the PDPs, you can also edit the application description. To edit the details, select the application from the list and click Edit. The Edit Application page is displayed.

Except for the Application Name and Application group selection fields, you can modify the other fields while editing a selected application. For example, if you want to associate an application with more PDPs than the existing ones, it can be done by editing the application. Similarly, if you want to disable Xacml Log field for a particular application that is otherwise currently enabled, you can uncheck the field by editing the concerned application.

Deleting an Application

To delete an application, select the application and click Delete. You are prompted to confirm the deletion. Click Yes to delete the selected application or click No to cancel the action.

Viewing PDPs

When you click the View PDPs icon, a pop-up window is displayed that lists the PDPs associated with the selected application. When a user tries to access any resource of a particular application, the application (PEP) sends a request for the authentication of the user authorization to its corresponding PDPs. The PDP in return verifies the request by dynamically checking each policy created under that application for that particular user-role. For multiple PDPs, if the first PDP fails to respond to the request, it is passed on to the next PDP. This process continues until the request is addressed by either of the PDPs associated with the application.

Figure 7-7 List of Entitlement Servers

The Resource Management page lists all the resources created under the selected application in a hierarchy showing application group name at the top. If the number of resources is large, the Search option provided in this page helps you search for the required resource without navigating the whole tree structure.

Viewing Resources

The View Resources button displays the resource tree for the selected application.

Adding Attribute Source Information

Attribute source provides information against which policy conditions are evaluated. Attributes are created to add additional information about a resource. Evaluation of policy requires access to information referenced by the policy. Often the information required is not available in the administration where the policy is retrieved. Attribute source, which is a policy information point, stores these additional conditions as attributes. Also different attribute sources can be created with regard to different database types. Depending on the datasource type, attribute source of type database, LDAP, or Java can be created. The process of creating an attribute source is explained later in this chapter.

Downloading an Agent Configuration

The Agent Config button of any application provides you with the details of the agent configurations, such as PEP configuration and PDP details. You can also download the PEP configured for the selected application by using this button.

To download an agent configuration, you must:

Step 1 Click Agent Config for an application.

The Download Agent Config for Application page is displayed.

Figure 7-8 Download Agent Config for Application

Step 2 Update the Decision Cache-enabled parameter to True if you want to enable caching, or False to disable caching.

Step 3 Set Cache Refresh Type field to all. If it is set to only updated, during the cache refresh process only the changed data is copied from the PDP and is updated in the PEP cache. When set to all, during the cache refresh process all the data from the PDP cache gets copied to the PEP cache.

Step 4 Update cache-type parameter either to TTL (time to live) or Session.

Step 5 Update the time interval in minutes for the cache to refresh the cached-data from the PDP in the CACHE_INTERVAL parameter. For example, if you want the time interval to be 5 minutes, enter 5 in the Interval box.

Step 6 If you set the Prefetch field to true, all the application data is pre-fetched after the server starts up. No prefetch is possible if this field is set to false.

Step 7 Enter the Prefetch API. For example, if you enter isUserAccessAllowed as the method, then the data related to this method and its overloaded methods are prefetched. This field is useful only when Prefetch is enabled (when the Prefetch field is set to true).

Step 8 Enter the Transaction Timeout Interval in minutes. This element decides the time interval (in milliseconds) for which the PEP component should wait for the response after making a request to the PDP, so as to assess the status of the PDP as active or inactive. Thus if the value is set to 1, when the PEP makes a request to the PDP for status check, if the PEP does not receive response within 1 minute, the PEP sets the status of that PDP to inactive in its own cache.

Step 9 Set the Refresh Type either to Update or Invalidate. Setting it to invalidate erases the cache during the refresh cycle. If set to update, the PEP cache is updated according to the value set for cacherefreshtype attribute (as explained earlier).

Step 10 Select the PDPs. When multiple PDPs are associated with an application, the downloaded configuration file provides details of each PDP.

Step 11 Enter the Admin API URL, which is the URL where the PAP runs.

Step 12 Enter the Admin API username and password.

Step 13 Select the required protocol (SOAP, HTTP, or RMI) from the drop-down list.

Step 14 Enter the resource domain name, which is, the repository name under which the user logs in.

Step 15 Enter the HTTP proxy URL of the PAP and the port number.

Step 16 Click Download PEP button. The the pep_config.xml file is downloaded into the specified location in your system.

Begin Policy Lookup

CEPM PDP can now store policies applicable to a request in a readily accessible manner. Policy identification is a complex step, given the various associations among the entities in the CEPM conceptual model, that requires execution of elaborate stored procedures on the database at request processing time. This step can now be off-loaded by the PDP runtime—policies applicable to a combination of subject, role bundle, context, and resource are stored in the policy table for easy look-up of the PDP. Policy administrators may start (and update) the policy table independent of a request processed by the PDP.

As a prerequisite for beginning policy lookup, make sure that sufficient DB space is allotted for the policy lookup table in your database. A minimum estimation in this regard might be—for 100 users, 100 groups, 100 roles and 10,000 resources with 20% entity compounding growth and 25% resource compounding growth, 8GB of database tablespace for policy lookup table.

One may start the priming of the policy lookup table manually from the UI in the following manner:

Step 1 Run Index_script.SQL from the following database directory.

•For Oracle: Run this script from /CEPM-V3.3.0.0/db/scripts/oracle folder

•For MSSQL: Run this script from /CEPM-V3.3.0.0/db/scripts/mssql folder

Note Since the policy lookup table is expected to be huge in size, indexes should be created accordingly. CEPM comes with a default index called SEC_SUP_COMP on the combination of columns, such as SEC_CONTEXTID, SEC_ROLEBUNDLE_ID, SEC_APPID, SEC_USERID and SEC_RESID in tandem. Additionally recommended indexes should be created individually on SEC_USERID, SEC_RESID and SEC_APPID columns.

Step 2 Click 'BeginPolicyLookUp' link for the selected application.

Figure 7-9

Prefetch Policy Lookup

Step 3 Click 'START' link next to the 'PolicyLookUpForUser' if all the users policy data must be processed. There are similar links for group and role.

Caution Do Not run this process concurrently (for different entities).

When the policy lookup is started for the first time, the data fetch may take a long time (in hours) to complete depending on the size of the data. During this process, the policy lookup popup window might time out and thus the user may automatically log out from the PAP. However, the database update continues to run.

Caution At this stage, do not re-login to the PAP for checking the policy lookup status.

There will be a considerable increase in the database load while this process runs. To check the progress, monitor the database log (for example, alert.log in Oracle) for any error message, such as running out of space for the policy lookup table to grow, and so on.

When the BeginPolicyLookup process is believed to be done, the user must look carefully in the pap log for errors, and consult customer support if there are any errors. Though the PAP UI may show that the update has successfully finished, you must get it confirmed from the PDP logs for a success message.

The 'START' link is replaced with 'UPDATE' link once it is clicked.

Once all the data on the system is processed, fresh updates can be applied in multiple ways as documented below:

•Through the PAP UI, from where you can update the policy lookup table for all changes that an administrator has done in the last 'x' minutes or since the table was last updated.

•By making use of DB cron jobs that run every configured interval to update the table.

•By using triggers—this is useful when administrators make changes to policy data and the change needs to be applied instantaneously to the policy lookup table so that the PDP has the right policies and not stale data to service an authorization decision.

Update Policy Lookup from the PAP UI

To update the ACL table from the UI:

Step 1 Click the 'UPDATE' link for each entity. Once you click the 'UPDATE' link, a pop-up window shows three options for how to update the policy table.

Figure 7-10 Update Policy Lookup

The options are -

•Entire Update—Select this option if you want to update the entire policy data. Use this option only if you have done a lot of changes to the policy data.

Note While selecting the `Entire Update' option, the Application DB Fetch Information pop up needs to be manually refreshed to reflect the updation on entire policy lookup table.

•Partial Update—Select this option to update the policy table since it was primed.

•Update last 'x' minutes—Enter the time interval, say 'x' minutes, if you want the table to be updated for changes every 'x' minutes.

In case of large volume of data, the process of priming might take much time.

Update Policy Lookup using DB Jobs

Make sure that you have started the policy lookup from the PAP UI before using this feature. You can update the ACL table for every `x' minutes by employing DB Jobs.

For Oracle, this is done by executing the Jobsutility.sql script which is available in /CEPM-V3.3.0.0/db/scripts/oracle folder. To update the Policy lookup table using the DB Job:

•Open any Oracle client (for example, SQL Plus).

•Execute Jobsutility.sql script from /CEPM-V3.3.0.0/db/scripts/oracle folder.

•This will prompt you to enter the frequency. Enter the frequency in minutes. For example, if you enter 5, the Policy lookup table gets updated after every 5 minutes.

For MSSQL (2005 only), this is done by executing the Jobsutility.sql script which is available in /CEPM-V3.3.0.0/db/scripts/mssql folder. To update the Policy lookup table using the DB Job:

Open the Jobsutility.sql file and manually update the following parameters available under the heading "/* Parameters need to assign */":

For example, if the login name is CEPM, database name is CEPMDB, Server name is WINSQL51, and the time interval is 5 minutes, the "/* Parameters needed to assign */" section should look like:
SET @VLOGIN_NAME=N'CEPM'
SET @DB_NAME =  N'CEPMDB'
SET @VSERVER_NAME=N'CEPM-WINSQL51'
SET @VTIME_INTERVAL=5
Save and execute this file. After execution, the policy lookup table is updated every 5 minutes.

For DB2, follow this procedure to update the policy lookup table:

Step 1 In the DB2 Task Center, go to New > Task. The New Task pop-up window appears.

Step 2 Select the Task tab and enter the Task Name.

Step 3 Select the Command Script tab and enter the following command:
CONNECT TO CEPMDB;
GET_DECISIONSJOBS(15);
GET_DECISIONS_ROLESJOBS(15);
GET_DECISIONS_GROUPSJOBS(15);
Here, 15 refers to the time interval (in minutes).

Step 4 Select the Schedule tab, check the Repeating Schedule, and enter the Repeating Interval.

Figure 7-11 Update Policy Lookup using DB jobs

Step 5 Select the Notification tab, enter the Journal Message for success and failure actions.

Step 6 Select the Task Actions Tab and specify the condition on which to run the task.

Step 7 Select the Security tab and click OK.

This creates the desired task.

Update Policy Lookup via triggers

Ensure that you have started the policy lookup from the PAP UI before you use this feature. You can update the ACL table via custom trigger. After the trigger is invoked, it inserts or updates the policy look up table automatically whenever a policy is created or updated. To activate this trigger, execute the Triggersutility.sql script from the following directory:

For Oracle—/CEPM-V3.3.0.0/db/scripts/oracle/Triggerutility.sql

For MSSQL—/CEPM-V3.3.0.0/db/scripts/mssql/Triggerutility.sql

For DB2—/CEPM-V3.3.0.0/db/scripts/db2/Triggerutility.sql

Policy Decision Points

The PDPs are services that run on different servers, but share a common database. The PDP evaluates application-specific distributed entitlement authority that evaluates authorization policies and is responsible for communicating with the PEP. The PDP is a unique, scalable, enterprise-ready solution for achieving fine-grained distributed entitlement. Existing solutions rely on re-purposing centralized Identity Management solutions to also act as a single, central entitlement authority. However, the existing model has largely failed to meet the scalable, application-specific, fine-grained authorization needs of enterprises and does not reflect the practical deployment considerations that require distributed decisions to be made closer to applications, rather than at a central authority.

Figure 7-12 Policy Decision Points Flow diagram

When a user tries to access a resource covered under CEPM, the agent (the PEP) embedded within the application sends a request to the concerned PDP in a defined format. The PDP evaluates the policy defined for that particular user by taking into consideration the requested data and communicates the decision to the PEP.

The PAP and PDP can be deployed either in a shared or distributed mode. If shared, these components have a common database. Otherwise, a different database is configured for the PAP and PDP giving sufficient scope for an effective synchronization of event taken place in PAP in the PDP database. Refer to CEPM Installation and Configuration Guide for more information on PAP-PDP DB Separation.

In CEPM, the user can create many PDPs and associate them with any application. These services run in different ports on different web servers. When any of the web servers go down, another PDP takes the request and continues the service.

If authorized by the superuser, the user can create many PDPs. These PDPs are then linked with one or more applications registered within the administration console. Other than this, the PDPs connect with existing information repositories, such as LDAP, AD, databases, and IdM, which are referred to as Policy Information Points (PIPs). As far as the PEPs are concerned, one or more PEPs can be connected to a single PDP and one or more PDP can be connected to a single PEP. To make the PDP authentication faster, more than one PDP can be associated with a single application. This helps keep the PDP-PEP communication very much alive even if one of the PDPs fails.

When you choose Home > System Config > Policy Decision Point, a list of PDPs is displayed.

Figure 7-13 Policy Decision Point

This page lists all the existing entitlement severs (PDPs) with their details, such as name, owner, and end points. You can add a new PDP by clicking Add PDP. Apart from this, a few actions can be carried out for each PDP by clicking the corresponding buttons, such as Edit, Delete, View Applications, Refresh PDP Cache, Set Log Level, and Server Status.

Adding PDPs

You can add new PDPs by clicking Add New PDPs. The Register PDPs page is displayed. Initially, this page is divided into three main areas (four if you select HTTPS). The first area deals with the PDP information, the second area deals with agent-PDP communication settings, and the third area basically carries the logging and monitoring settings. If HTTPS is selected as the protocol, this area is used to provide the HTTPS details.

To add a new PDP, you must:

Step 1 On the List PDP page, click Add PDP.

The Register PDP page is displayed.

Figure 7-14 Create Policy Decision Points

Step 2 Enter the PDP details:

•PDP name and description—Name of the PDP and a brief description about the PDP.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

•If you want to create an in-process PDP, check Yes. The Host and Port fields are disabled. Click No to define the external PDP.

What is In-process PDP?

The in-process PDP is a special component replaced for the CEPM agent (PEP), which is embedded in the client-side application for sending, acknowledging, and implementing policy requests to and from the PDP. This component is very useful when the client-side application is a standalone (desktop) application. The in-process PDP is the merger of the PEP and PDP defined within the normal Cisco environment. For further details about in-process PDP, refer to the CEPM In-Process PDP Deployment Guide.

–Enter the endpoints, HTTP URL prefixes for web services that are accessed through HTTP by using the information panel in the administrative console. The HTTP URL prefixes provide location-specific information and are used to form complete endpoint URLs. In CEPM, you need to define the PDP endpoint URL in http://[host]:[port]/pdp/admin/Pdp Admin format.

Note Enter the host IP and the port number. When you opt for in-process PDP, there is no need to define the host and port number as both the agent (PEP) and the PDP are embedded and run on a single machine. Checking Yes for in-process PDP disables the Host and Port fields.

–Check whether the transport protocol belongs to HTTP or HTTPS. If you select HTTPS, another section called TrustStore Details is included above the Logging and Monitoring section. This section allows you to enable SSL. For more details about configuring SSL, refer tothe CEPM Installation and Configuration Guide.

Step 3 The Shared Repository check box is checked by default. This means the PAP and PDP are sharing a common database. Uncheck the check box if you want separate databases for the PAP and PDP. For details about PAP-PDP DB Separation, refer to the CEPM Installation and Configuration Guide.

Step 4 Enter the Agent - PDP Communication details:

•Check the required authentication type. Check Local in case of local database or External if you choose LDAP.

•Enter the username and password, and retype the password.

Step 5 Truststore Details: This section is available only if HTTPS is selected as the transport protocol. This section defaults to one-way SSL. For two-way SSL, you must check Enable 2way SSL. Enter the following parameters for this purpose:

•Trust Store password—Enter the keystore password.

•Trust Store Location—Enter the location of the SSL certificate. You can mention the absolute path or relative path of the certificate. For example, if you are providing the relative path, you must enter .keystore in the Trust Store Location field (ensure that the SSL certificate is copied in CEPM_HOME/config folder). Otherwise, you can enter the absolute path. For example, c:/test.cer

Creating a keystore?

The secured HTTP connection (https) system provides authentication and encrypted communication, which are widely used on the World Wide Web for security-sensitive communication. In order to enable secure HTTP connections, you must enable communication over the Secure Socket Layer (SSL), which ultimately ends up with the creation of a keystore. To enable SSL for Tomcat, you must do the following:

–Run the following commands from the command line:
JAVA_HOME\bin\keytool -genkey -alias tomcat -keyalg RSA
Enter keystore password changeit
What is your first and last name? John Doe
What is the name of your organizational unit? Software
What is the name of your organization? Cisco
What is the name of your City or Locality? New York
What is the name of your state province? NY
What is the two-letter country code for this unit? US
Is CN=John, OU=Software, O=Cisco, L=New York, ST=NY, C=US correct?
[no]:  yes
These instructions help you generate the keystore file (.keystore). This file is in the user profile folder. On Windows, for example, C:\Documents and Settings\<User>.

–Edit the server.xml of Tomcat available in TOMCAT_HOME\conf folder (if you are using the bundled (pre-packed) Tomcat, it will be in CEPM_Home\external\apache-tomcat-5.5.17\conf folder) and uncomment the Connector Port=8443.

–Refer to Appendix D for the sample server.xml file.

–Copy the .keystore file to the CEPM_Home\config folder.

–Copy the .keystore file to the CEPM_Home\external\apache-tomcat-5.5.17\webapps\CEPM\WEB-INF\classes folder.

–Start the Tomcat Server. You should be able to access the CEPM from https://host:port/cepm.

–Edit the PDP and change the port to 8443, protocol to https and enter the trust store location as .keystore.

You can run the PEP with the JVM variable -Djavax.net.ssl.trustStore=<path-to-keystore-file>. You can use the same keystore on the client side too.

Step 6 Keystore Details: This section is available only if Enable 2way SSL is selected in the Truststore Details section. Enter the following parameters for this purpose:

•Keystore Password: Enter the keystore password.

•Keystore Location: Enter the location of the SSL certificate. You can mention the absolute path or relative path of the certificate. For example, if you are providing the relative path, you must enter..keystore in the Trust Store Location field (ensure that the SSL certificate must be copied in CEPM_HOME/config folder). Otherwise, you can enter the absolute path, for example, C:/test.cer

Step 7 Enter Logging and Monitoring parameters:

•In the Logging and Monitoring Section of the page, click Local File System if you want the XacmlRequest and XacmlResponse to be logged in a local file system. Otherwise, click Database.

Step 8 Click Create.

This adds the new PDP to the list.

Editing PDPs

To edit the parameters of any of the PDP, select the PDP, and click Edit. The Edit PDP page is displayed.

You cannot change the PDP name as any changes made to this parameter affects the whole structure of the Delegate Administration due to the association of the PDP with one or more applications. Other references such as host, port, username, and password can be changed. When editing is done, click Update to save the changes.

Deleting a PDP

To delete a PDP, click Delete next to the PDP button. You are prompted to confirm the deletion. Click Yes to delete the selected group or click No to cancel the action.

Note When a PDP is deleted from the list, the association of the PDP with the corresponding applications is severed.

Refreshing the PDP Cache

The caching mechanism is widely used to enhance the performance of web-based applications. CEPM uses this mechanism for the PEP and PDP. It also supports prefetch of data when the server starts up. Caching is done on the basis of users who are the subject of the PEP request. The caching parameters are set in the <cache> tag of the pdp_config.xml. This sets the refresh time of the PDP cache for any or all users.Instead of doing this, you can refresh the PDP cache for any particular user under a selected role bundle and context.

To refresh the PDP cache for a specified user, you must:

Step 1 Select the PDP and click Refresh PDP Cache.

The Refresh PDP Cache page is displayed.

Figure 7-15 Refresh PDP Cache

Step 2 Enter the username on the basis of which the PDP cache is to be refreshed

Step 3 Enter the resource name. This refreshes all the data relevant to the specified user pertaining to this resource.

Step 4 Enter the role bundle and context to set the limitation of cache refresh. This is not mandatory as the application takes the default role bundle and Global context as the default value for these parameters if not explicitly mentioned in this page.

Step 5 Click Submit. This automatically refreshes the configured user data under the specified resource with the given role bundle and context.

Viewing Applications

The View Applications button enables you to list all the applications associated with the selected PDP. To view the application, click the corresponding View button. The Applications page is displayed.

Figure 7-16 View Application

This table contains information about the applications, their owners, and few additional functional buttons for every listed application. You can add a new application to the selected PDP from this page by clicking Add New Application. Detailed functionalities of these buttons are explained in Applications.

Viewing or Setting the Log Level

A server log is automatically created and maintained for all the activities performed by the concerned PDP. In CEPM, these logs are generated using the com.cisco.pdp package which is set as the default package in the logging.xml file. For any application only if the xacml log is enabled while creating that application. For example, when the PEP sends a request to the PDP, the PDP server maintains a history of that requests along with the response it returns.

To view or set the log level, you must:

Step 1 On the PDP page, select a PDP and click Set Log Level. The PDP Log Level page is displayed.

Figure 7-17 PDP Log Level

This table contains the URL of the selected PDP along with the existing log level.

Step 2 To reset the log level, select the level from the Log Level drop-down list. The logs are separated into distinct logs, called as log levels:

•INFO level—Designates informational messages that highlight the progress of the application at coarse-grained level.

•DEBUG level—Designates fine-grained informational events that are most useful to debug an application. This is the widely used log level as it generates all the activities irrespective of the nature of its occurrence. When you set DEBUG as the log level, the log shows all the records specific to that PDP.

•WARN level—Shows all the warning messages generated by the PDP. In case of a situation which seems to be potentially harmful for the application, the PDP raises a warning which is logged in the server log if WARN level is selected.

•ERROR level—Records all diagnostic information on all errors occurred. When you select this level for a PDP, the PDP log shows only the errors that occurred during the runtime.

•FATAL Level—Designates very severe error events that presumably leads the application to abort.

Select any of these levels based on your need.

Step 3 Click Go to save the setting.

Server Status

At times, one or more PDPs are dead due to some connection failure or other technical reasons. This causes the PEP-PDP communication to go down unless the PEP is associated with other PDPs. After creating a PDP, you can check the status from the PDP table.

Click PDP Status for that PDP. A pop-up window is displayed that contains the message whether the selected PDP is alive or dead.

Figure 7-18 Server Status

Context

In CEPM terminology, context is a set of special circumstances that surround certain events that take place in this application. CEPM allows you to create many contexts in a hierarchical order with a default context called Global context. CEPM supports a hierarchical context construct. This enables any organization to define default policies while allowing partners to override/extend policies within the context of their own users and requests.

The key requirement is centered on the ability to map users to roles, or roles to resources within a context. Context is hierarchical and represents a customer (subcontexts could represent divisions or other entities within a customer that may have different entitlements, for example, customers who have grown through M and A).

CEPM allows:

•all entities (user, groups, roles, resources) and mappings to be defined within context

•default context, which allows encapsulating of default policies and mappings that can be inherited

•hierarchical context

Context gains more importance while a mapping is done. For different contexts, you can create different mapping under the same application or application group. This culminates in setting the security parameters more accurately and minutely. For example, a user called Mary can have two different roles in two different contexts. When Mary is mapped with a role called Internal Dev, the newly created mapping can have different values of user attributes and role attributes in different contexts. The PDP while responding to a request from PEP, apart from other parameters, gives the decision on the basis of the context passed within the request. If no context is selected, the application shall consider Global as the default context.

You can create many contexts in the PAP in the shape of a hierarchy.

To create a new context, you must:

Step 1 Choose System Configs > Context.

Step 2 Select the application group or application under which you want to create the new context. The Context page is displayed, which contains a context tree carrying the Global context and the existing contexts created from the application group level.

Figure 7-19 Context Home Page

Step 3 Select the level under which the new context shall be accommodated and click Create Context next to the selected level. The Add Context page is displayed.

Figure 7-20 Add Context

This page displays the fully qualified name of the selected context.

Step 4 Enter the name of the new context and a brief description.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

Step 5 Click Save. The new context is added in the defined level.

Note If your browser is Internet Explorer 6, you may encounter "Class doesn't support automation" Java Script Error at this stage. If you get this error, run the following commands in the Run dialog box to re-register the DLLs and other supportive files:

•REGSVR32 msscript.ocx

•REGSVR32 dispex.dll

•REGSVR32 vbscript.dll

•REGSVR32 scrrun.dll

•REGSVR32 urlmon.dll

For example, to re-register msscript.ocx, go to Start > Run. Enter the above command in the Run dialog box and click OK. A confirmation message window pops up. Click OK.

Apart from the Global context, wherever a context comes into use, the context hierarchy shall contain contexts created under the application group and application. The user can select a required context from the hierarchy by clicking the context.

Figure 7-21 Manage Entitlement by Resources

When you select Global context, the CEPM takes all contexts created under the selected application dropdown.

Evaluation of policies in the context point of view:

When the PEP sends a request consisting of a context, the PDP searches for the policy under that context level. If no policy is found under that specified context, the PDP searches for its parent level. If the parent level has a policy on the said resource, it will sends the decision accordingly. If not, the PDP extends the search to one more level above the current level. In this way, the search is extended until it reaches the Global level and an appropriate decision is communicated.

Application Group Types

If you need to associate metadata with the application group, which might be required in the decision-making process or if the application requires it after getting the decision from the PDP, you can use these metadata. As the title suggests, an application group type is a special component used while creating application groups to provide additional security parameters to be considered during policy evaluation. The additional security parameter also provides a great deal of formality through evaluation of attributes for different application groups. This culminates the authentication of the PDP on the line of the application group types that constitute the specified application group.

To view and create application group types, you must:

Step 1 Choose System Config > Administer > Application Group Type. The Resource Type page is displayed, which lists all the default and existing resource types.

Figure 7-22 Application Group Types

The list contains a default application group type to be used while creating an application group without selecting any types. From this page, you can create, edit, or delete an application group type. Also you can view the attributes that constitute an existing application group type.

Step 2 To create a new application group type, click Add. The Create application group type page is displayed.

Figure 7-23 Create or Update Application Group Types

Step 3 Enter the name and a brief description about the application group type.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

In the Attributes section, you can add any number of attributes to the new application group type. While creating an application group using this type, these attributes are evaluated as per the attribute types.

Step 4 Enter the attribute name.

Step 5 Select the attribute type from the drop-down list, which contains all the attributes that exist in the repository. If you select enum as type, you must set the enumeration values to the attribute by clicking the View Query button.

Step 6 Set the attribute value type to either single or multiple.

Step 7 Set the Mandatory field to either Yes or No. When set to `Yes', you must give the attribute value while using this attribute in creating an application. To this effect, the Attribute value field for the corresponding attribute in the Create Application Group page is shown as a mandatory field. For example, an application group type called MyApp Type of type String is created and the Mandatory field is set to Yes. While creating an application group using this application group type, you find the My AppType field as mandatory.

Step 8 To add more attributes to the application group type, click Add Attributes.

Step 9 After creating the required number of attributes, click Save.

This creates the new application group type. You can also add more attributes to any of the existing application group types by editing the same.

Application Types

The Application Settings architecture provides many attributes that can be applied to the applications as its individual properties. These attributes are examined at run time by the PDPs in order to give decision in response to the concerned PEP request. Application types are metadata wrapped with the application that might be required in the decision making process.

While creating an application, you can have your own application type with a predefined set of attributes for making the PDP decision more stringent and particular. The additional security parameter also provides a great deal of formality through evaluation of attributes for different resources. This culminates the authentication of the PDP on the line of the application types that constitute the specified application. You can add any number of attributes to the application type. CEPM has a default application type, so it is not mandatory to create new application types before creating a resource.

If you select an application group, all the application types created under the Global label and the application group level (under which the application is created) is shown in the table. Similarly, if you select an application, all the resource types created under the Global label, application group, and the selected application are listed in the table.

To view and create resource types,you must:

Step 1 Choose System Config > Application Type. The Application Type page is displayed, which lists the default and existing application types.

Figure 7-24 Application Types Home Page

Step 2 To add a new application type to this list, click Add.

The Create/Update application type page is displayed where you can create a new application type and add the desired number of attributes to it.

Figure 7-25 Create or Update Application Type

Step 3 Enter the name and a brief description about the application type.

In the Attributes section, you can add any number of attributes to the new application type. While creating an application using this type, these attributes are evaluated as per the attribute types.

Step 4 Enter the attribute name.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), Hyphen(-), and Asterisk(*).

Step 5 Select the attribute type from the drop-down list, which contains all the attributes that exist under the repository. If you select enum as type, you must set the enumeration values to the attribute by clicking the View Query button.

Step 6 Set the attribute value type to either single or multiple.

Step 7 Set the Mandatory field to either Yes or No. When set to `Yes', you must give the attribute value while using this attribute in creating an application. To this effect, the Attribute value field for the corresponding attribute in the Create Application page is shown as a mandatory field. For example, an application type called Port of type Int is created and the Mandatory field is set to Yes. While creating an application using this application type, you will find the Port field as mandatory.

Step 8 To add more attributes to the application type, click Add Attributes.

Step 9 After creating the required number of attributes, click Save.

This creates the new application group type. You can also add more attributes to any of the existing application group types by editing the same.

External Attribute Sources

The PDP evaluates application-specific and enterprise authorization policies. The PDP also connects with existing policy information repositories, such as LDAP and databases, that are referred to as Policy Information Points (PIPs).

All additional user information for a particular application can be directly imported from the external user attribute sources, such as LDAP and AD. Similarly, with an intention to minimize database space, additional application metadata can be called from external sources, such as database PIP.

CEPM provides two types of external attribute sources:

•User attribute sources

•Application attribute sources

User Attribute Sources

CEPM allows you to import users and user groups from an LDAP directory service into the PAP. A user attribute source (also called a user store) is a virtual store of users and user groups created in the PAP and is configured to refer to the users and user groups in the LDAP directory.

This feature is useful when the application to be secured already contains a large number of users and user groups stored in an LDAP directory. Thus, rather than creating these users and user groups again in the PAP, you can import them from the existing LDAP directory.

CEPM supports the following LDAP directory services for importing external users and user groups into the PAP application:

•Sun One Server 5.2

•Novel eDirectory Server 8.7.3

•Active Directory 2000 Server

In administration console, you can create, update, view, and delete the user stores for an application or for an application group.

User Synchronization

The import process can be done manually or can be automated. The process of automatically importing users from an LDAP directory to the PAP application is called synchronization. In this case, after an LDAP directory is configured for synchronization with the PAP application, for any new user that is created in the LDAP directory, the user gets automatically created in the PAP application.

For synchronization of LDAP directory users with the PAP users, the Base Distinguished Name (base DN) of the LDAP directory should be specified in the PAP application when a user store is created. Multiple Base DNs can also be specified for a single user store. If multiple base DNs are specified per user store, the users belonging to the multiple base DNs are merged together and then synchronized with the PAP application.

The top level of the LDAP directory tree is the base, referred to as the base DN. Assume that a person works for a U.S. E-commerce company called FooBar, Inc., which is on the Internet at foobar.com. The base DN for the LDAP directory service implemented for this company can be represented in one of three forms:

•base DN in X.500 format:

o="FooBar, Inc.", c=US

•base DN derived from the company's Internet presence:

o=foobar.com

•base DN derived from the company's DNS domain components:

dc=foobar, dc=com

Creating a User Attribute Source

To create a user attribute source, you must:

Step 1 Choose Home > System Configs > External attribute source > User attribute sources.

The List User Store page is displayed, which shows the existing user stores.

Figure 7-26 User Attribute Source

Step 2 Click Create User Store. The LDAP Information page is displayed where you can create a user store for the users and user groups that are in the LDAP directory.

Figure 7-27 Create User Store

Step 3 Enter the following information:

•LDAP Info Type—Select the appropriate LDAP directory service from the list.

•LDAP Info Name—Enter the user store name.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

•LDAP Host—Enter the URL of the machine where the LDAP directory service is running.

•LDAP Port—Enter the port on which the LDAP directory service is available.

•Base DN—Enter the base DN for the directory service. Example: dc=cepm, dc=net

•User DN—Enter the user DN for the directory service. This should be the user who has permissions to access information about all the users and user groups under the base DN specified in the directory service. For example, uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot

•Password—Enter the password for the user.

•Confirm Password—Re-enter the password.

Note In the initial stage of creating a user attribute source, it is not mandatory to provide the User DN Password and Confirm password, but these values are mandatory in the following instances:

•when searching for a user in the specified Base DN

•when changing the LDAP Sync status from Inactive to Active.

These parameters can be evaluated at any stage by using the Edit LDAP Info feature by selecting the concerned user attribute source.

•User attributes—Enter the attributes of the users that are defined in the LDAP directory service, which you want to view in the PAP console. You can enter multiple attributes separated with a comma. For example: User_Location, User_ID.

•Enable SSL—This section gives way to enable SSL. CEPM does not support SSL configuration for Novel e-Directory. For more details about configuring SSL, refer to the CEPM Installation and Configuration Guide.

Figure 7-28 Create User Attribute Source

•Truststore Details—This section is available only if Enable SSL is selected as the transport protocol. This section defaults to one-way SSL. For two-way SSL, you must check Enable 2way SSL.

Enter the following parameters for this purpose:

–Trust Store Password—Enter the keystore password.

–Trust Store Location—Enter the location of the SSL certificate. You can mention the absolute path or relative path of the certificate. For example, if you are providing the relative path, you must enter .keystore in the Trust Store Location field (ensure that the SSL certificate is copied in CEPM_HOME/config folder). Otherwise, you can enter the absolute path, for example, C:/test.cer.

•Keystore Details—This section is available only if Enable 2way SSL is selected in the Truststore Details section. Enter the following parameters for this purpose:

–Keystore Password—Enter the keystore password

–Keystore Location— Enter the location of the SSL certificate. You can mention the absolute path or relative path of the certificate. For example, if you are providing the relative path, you must enter .keystore in the Trust Store Location field (ensure that the SSL certificate is copied in CEPM_HOME/config folder). Otherwise, you can enter the absolute path, for example, C:/test.cer.

Step 4 Click Test to test whether the connection is successfully established with the specified LDAP configuration.

Step 5 Click Create. A confirmation page is displayed.

Step 6 Click Yes if you want to configure multiple domain names for synchronization for the same Store Name you created earlier, otherwise click No.

If you click Yes, the screen shown in LDAP Synchronization Information is displayed.

Figure 7-29 LDAP Synchronization Information

Step 7 Enter value for the Base DN. If you want to synchronize this Base DN, then select Active, otherwise select InActive.

Step 8 Click Create to create this base DN.

The page that contains the names of all the base DNs related to a Store Name configured for synchronization is displayed as follows:

Figure 7-30 LDAP Synchronization

You can edit or delete a particular Base DN from this list by clicking the Edit button or the Delete button respectively, under the Actions column. You can specify more Base DNs for synchronization for this store by clicking the Create button.

LDAP Synchronization

With the help of LDAP Sync option, the users created within the concerned LDAP are synchronized with the administrative console. As a result, the users are automatically listed in the Create/List Users page. This functionality enables the synchronization of users created within LDAP with the administrative console. As a matter of fact, when a user is created within the LDAP associated with the PAP, this event is synchronized with the database. So the same user is dynamically created in the Users List in the PAP. This option eases selection of users need to be imported for the purpose of mapping with groups and roles accordingly. The synchronization tool is integrated with the PAP, which enables the user to specify the branches that need to be synchronized with the database.

Note LDAP Group Synchronization is not supported in CEPM.

The Sync tool is also used in user-group mapping only if the group is already imported into CEPM. As a result, any user-to-group mapping defined in the user store is also synchronously reflected in the PAP.

Update User Attribute Source

You can update an existing user attribute source by selecting the LDAP and clicking the Edit button. Other than the LDAP name, you are allowed to change the LDAP host, port, base DN, and password.

Note You must reset the password every time you update any LDAP info. Because while editing an LDAP info, the passwords shown in the Password and Confirm Password fields are encrypted forms of the original passwords given during LDAP creation. If you click Update, without resetting the password, the encrypted password is stored in the database.

Application Attribute Source

For instance, two users with the same name (say Mary) have a policy on a resource. While creating a rule on the policy, you need to set a condition "Country is equal to US". In case of a large number of users, it is practically not possible to feed all user related data into CEPM. To overcome this, CEPM has a provision to retrieve the attribute values from an external source called application attribute source, which can be a database, an LDAP, a web service, or a Java class. As a result, in this example, if the user data is in the LDAP attached to the application, you can create an application attribute source with this, and also create an attribute called Country.

Application attributes sources are external entities to be used to make the entitlement policy more stringent using rules where you define the condition using the attributes from these sources. Application attribute source is a collection of application attributes. Application attributes are not in the CEPM database, but are external data sources, also called Policy Information Points (PIPs). A PIP can be an external database, or LDAP directory service, a web service, or a Java class.

If the application attribute source is connected over SSL, you can configure one-way and two-way SSL. Currently, you can enable one-way and two-way SSL only for LDAP PIP. For web service PIP, you can only ensble one-way SSL.

Note CEPM now enables the PAP administrator to make use of his own encryption scheme other than the default encryption facility provided with the application. Using this feature, you can plug-in third-party crypto modules to utilize other algorithms and externalized key management. This is done by updating the <callBackHandler> tag in the pap_config.xml file. Refer the CEPM PAP Configuration Guide for more information.

CEPM has a default application attribute source called Entitlement Repository with a set of default attributes named RolesForUser, GroupsForUser, UsersForRole, UsersForGroup, GroupsForRole, RolesFor Group and UserAttributeValue.

To create an application attribute, choose Home > System Configs > Administer > Application attribute sources. The Application attribute source Information page is displayed, which shows the existing attribute source names.

Figure 7-31 Application Attribute Sources

In this page, you can create a new application attribute source, edit an attribute source, and delete an attribute source.

CEPM supports four types of application attribute sources:

•Database PIP

•LDAP PIP

•Java PIP

•Web service PIP

Application Attribute Source of Database Type

This is also called Database PIP. When a PIP is created under a particular application, all the attributes created under that PIP will automatically be listed in the attributes drop-down menu to formulate conditions for a policy rule.

To create a new attribute source, follow these steps:

Step 1 On the attribute source information page, click Add attribute source for an application or for an application group. The attribute source information page is displayed.

Figure 7-32 Application Attribute Source of Database Type

This page displays the selected application name.

Step 2 Enter the value for the Attribute Source Name.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

Step 3 Enter the timeout interval. If caching is enabled, this is the time interval after which all the cache entries invalidate. For example, if the timeout is set to 10 seconds, the PIP cache entries become invalid after every 10 seconds.

Step 4 Enter the failover timeout interval. If there is a DB failure, the PDP sends a message to the PEP to retry sending the requests after the specified failover timeout interval.

Step 5 Select Database as the Attribute Source Type from the drop-down list.

Step 6 Select an appropriate database from the Attribute Base Type list. You can create DB PIP out of DB sources, such as Oracle (9i, 10g, 11g), MSSQL Server (2000, 2005), DB2, Sybase, and IDS (informix).

Step 7 Select a connection pool where in the database stores the attributes. It can be a Database connectionpool or WebLogic/WebSphere connectionpool. By default, the Database Connectionpool is selected.

Step 8 After the database connection pool is selected, the following section is displayed on the existing page.

Figure 7-33 Appplication Attribute Sources Database details

Enter the information related to database connection in this section:

•Database URL—Connection URL of the database instance. For example, if you are using Oracle, the URL should be in the following format - jdbc:oracle:thin:@<host>:<port>:devdb

•Database Driver Name—Database driver name.

•Database User Name—Enter the user name of the user who has permission to query the required information in this database.

•Database Password—Enter the password for the user who has permission to query the required information in this database.

•Database MaxConnections—This indicates the maximum number of connections that can be made to the database at any point of time.

•Database MaxConnectionTime—It indicates the number of seconds a connection can be checked out before being recycled when the database has reached the maximum connections allowed.

•Database IdleConnectionTime—It indicates the number of seconds after which a connection closes after being idle.

If WebLogic or WebSphere Connectionpool is selected, the following connection pool details must be entered:

Figure 7-34 Connection Pool

Enter the following connection pool details in this section:

•Context URL—It refers to the URL of the WebLogic/WebSphere server where the connection pool is configured.

•JNDI—It refers to the JNDI name of the WebLogic/WebSphere connection pool.

•Context Username—It refers to the username of the domain where the server is running.

•Context Password—It refers tot the encrypted password.

Step 9 Encryption scheme—This scheme is used to encrypt the passwords that are part of creating the attribute source, such as DB password, context password, and so on. You can select the default encryptor scheme pre-packaged with the CEPM application or can make use of your own scheme after integrating it with CEPM. In the above screenshot, Default Key has been selected as the encryptor scheme. Refer to the CEPM PAP Configuration Guide for more details on how to plug in thirdparty encryptor schemes.

Step 10 Click Test to check whether these connection details are accurate and can be used to access the specified database instance.

Step 11 Click Save. This creates a new application attribute source for the selected application.

You can edit or delete any of the existing attribute sources from the list.

Step 12 To add attributes to the source, choose Home > Manage Entitlements > Manage Entities > Application Attributes, select the application attributes source, and click Add Attribute.

Adding Attributes to the DB Attribute Source

To add an attribute to the new source, you must:

Step 1 Choose Home > Manage Entities > Application Attributes.

Step 2 Select the required attribute source and click Add Attributes. The DataSource MetaData page is displayed.

Figure 7-35 Add Application Attributes

Step 3 Enter the following information related to the attributes in this section:

•Attribute Name—Enter the name of the attribute to create, for example, AccountInfo.

•Attribute Type—Enter the attribute type, such as string.

•Query to Execute—Enter the database query to execute, for example, select sec_user_name from sec_user_master.

•Query Returned—Select single if the query returns a singe value. Select multiple if the query returns multiple values.

•SQL/PL-SQL—Select SQL and/or PL/SQL based on the query language used while creating the above query.

Step 4 Click Save. This creates the new attribute. You can create multiple attributes for this attribute source by clicking Add Attribute.

In case of a rule created on a policy using this attribute, the PDP queries the external database as mentioned in the attribute source and not the database.

Using DB Attribute in Advanced Policy Configuration

Let's create an attribute source called AccountsDB and then define an attribute called GET_ACCOUNT_NAMES. The query to be executed for this attribute is:
Select account_names from account_master where account_manager=?
If John is the account manager and is managing accounts Acc1, Acc2, and Acc3, this would return three accounts during runtime. The rule can be configured on the policy as follows:

Figure 7-36 Rule Config

The input query details for the above rule is:

Figure 7-37 Query details

The above policy can be read as:
MessageAttribute[Account_Name] IN AccountsDB:GET_ACCOUNT_NAMES
where the account name is being passed in as a message attribute, this is the account name on which the user is trying to transact and this is compared against a list of accounts for which the user is responsible. If the account name is in the list returned, the user is entitled to transact/view the account or else the user is not entitled.

Using DB Attribute While Creating Typed Attributes

Another way the application attribute sources can be used is to map them to the typed attributes of different entities, such as user, role, group, and resource. By doing this, the attribute values are constrained by the values returned by the attribute source.

Consider the preceding example, and see how the account names can be mapped to a user attribute. Assuming that there is a userType with an attribute called Account_Names defined and this attribute is mapped to the attribute source AccountsDB:GET_ACCOUNT_NAMES. When you create a user of this type, automatically the Account Names are populated for the user attribute and you can choose the right value for it. Further, the user attribute can be used in the policy rules.

Application Attribute Source of LDAP Type

This is also called LDAP PIP. Application-specific attributes can be created within the LDAP PIP. For example, if the attribute is created as Contact No in a PIP, the same attribute is listed in the list of attributes to be selected for formulating a rule on a policy where the concerned user is a subject.

To create a new attribute source of type LDAP under an application, you must:

Step 1 On the Application attribute source page, click Add attribute source. The attribute source Information page is displayed.

Step 2 Enter the source name.

Step 3 Enter the timeout interval. If caching is enabled, this is the time interval after which all the cache entries invalidate. For example, if the timeout is set to 10 seconds, the PIP cache entries become invalid after 10 seconds.

Step 4 Enter the failover timeout interval. If there is a DB failure, the PDP sends a message to the PEP to retry sending the request after the specified failover timeout interval.

Step 5 Select the attribute source type as LDAP.

The LDAP and Encryption scheme sections are added to the page.

Figure 7-38 Application Attribute Source-Encryption scheme

Step 6 Enter LDAP directory connection details:

•LDAP Type—CEPM supports Novel eDirectory Server 8.7.3, Sun One Server 5.2, and Active Directory 2000 Server.

•Ldap Host and Port—Enter the host IP address and port number of the machine where the specified LDAP is running.

•Ldap User DN—Enter the user DN of the user who has permission to query the required information in this LDAP directory.

For example, uid=john,ou=administrators,ou=topologymanagement,o=netscaperoot.

•Ldap Base DN—Enter the base DN information for this LDAP directory.

For example, dc=foobar,dc=co,dc=uk.

•Password—Enter the password for the user who has permission to query the needed information in this LDAP directory.

•Enable SSL—If you are using HTTPS, you must enable SSL. Depending on the type of authentication you can choose either one - way or two-way SSL. In one way SSL (which is commonly used), only client authentication is done, but in two-way SSL, mutual authentication is done by both client and server. (For more information on how to configure SSL in LDAP, refer to the CEPM Installation and Configuration Guide.)

From the Enable SSL drop-down list, select either one-way or two-way SSL.

Figure 7-39 Application Attribute Source- Truststore

The Truststore Details section is available only if HTTPS is selected as the transport protocol. This section defaults to one-way SSL. For two-way SSL, you must check Enable two-way SSL. The Keystore Details section is available only if the Enable two-way SSL is selected.

The following details must be provided for enabling SSL:

–Trust Store password—Enter the keystore password.

–Trust Store Location—Enter the location of the SSL certificate. You can mention the absolute path or relative path of the certificate. For example, if you are providing the relative path, you must enter .keystore in the Trust Store Location field (ensure that the SSL certificate is copied in CEPM_HOME/config folder). Otherwise, you can enter the absolute path, for example, C:/test.cer.

–Keystore password—Enter the keystore password.

–Keystore Location—Enter the location of the SSL certificate. You can mention the absolute path or relative path of the certificate. For example, if you are providing the relative path, you must enter .keystore in the Trust Store Location field (ensure that the SSL certificate is copied in CEPM_HOME/config folder). Otherwise, you can enter the absolute path, for example, C:/test.cer.

–LDAP Host—Enter the URL of the machine on which the LDAP directory is hosted.

–LDAP Port—Enter the port on which the LDAP service is available.

Step 7 Encryption scheme—This scheme is used to encrypt the passwords which are parts of creating the attribute source such as DB password, context password etc. You can select the default encryptor scheme pre-packaged with the CEPM application or can make use of your own scheme after integrating it with CEPM. In the above screenshot, Default Key has been selected as the encryptor scheme. Refer to the CEPM PAP Configuration Guide for more details on how to plug-in third party encryptor schemes.

Step 8 Click Test to check whether these connection details are accurate and can be used to access the specified LDAP directory.

Step 9 Click Save. This creates a new application attribute source under the selected application.

You can edit or delete any of the existing attribute sources from the list.

Adding Attributes to the LDAP attribute source

To add an attribute to the new source, you must:

Step 1 Choose Home > Manage Entities > Application Attributes.

Step 2 Select the required attribute source and click Add Attributes.

The DataSource MetaData page is displayed.

Figure 7-40 Application Attributes

Step 3 Enter the following information related to the attributes in this section:

•Attribute Name—Enter the name of the attribute to create, for example, UserInfo.

•Attribute Type—Enter the LDAP attribute type, such as cn, sn, and uid.

•Search Base—This is an LDAP related parameter on the basis of which the PDP queries the source. For example, ou=people,ou=external,dc=myapp,dc=in.

•Attribute Filter—This is also an LDAP related parameter. For example, &(uid=p*)(mail=p*)) or uid=p*.

Step 4 Click Save. This creates the new attribute. You can create multiple attributes for this attribute source by clicking Add Attribute.

In case of a rule created on a policy using this attribute, the PDP queries the external LDAP as mentioned in the attribute source and not the database.

Application Attribute Source of Java Type

An application attribute source of Java type is also called a Java PIP. When a policy needs to be evaluated using an external Java API, it is done by using a Java PIP. Java PIP is a collection of one or more Java attribute methods with a defined set of attributes. The return types of these attributes are also defined while creating the Java PIP. Java PIP supports return types of primitive data types and java.lang.String.

To create an attribute source of type Java under an application, you must:

Step 1 On the Application attribute source page, click Add attribute source. The attribute source Information page is displayed.

Step 2 Enter the Attribute Source Name.

Step 3 Select Java from the Attribute Source Type list. This adds the Attribute Base Type section in the page.

Figure 7-41 Application Attribute Source of Java Type

Step 4 Enter the Java PIP class name. This Java class must be in the classpath of the PDP application. The class name must be mentioned along with the package, for example, net.cepm.pip.java.TestClass (where net.cepm.pip.java is the package structure for the class TestClass).

Step 5 Click Test to verify the accuracy.

Step 6 Click Save. This creates a new attribute source in the attribute source page.

Adding Attributes to the Java Attribute Source

To add an attribute to the new source, you must:

Step 1 Choose Home > Manage Entities > Application Attributes.

Step 2 Select the required attribute source and click Add Attributes. The DataSource MetaData page is displayed.

Figure 7-42 Adding Attributes to the Java Attribute Source

Step 3 Enter the following attribute metadata in this section:

•Attribute Name—Enter the name of the attribute to create.

•Attribute Method—Enter the method name in the format methodName(?,?), where each question mark represents an input parameter to the specified method. For example, if the method add has three parameters, it should be mentioned as add(?,?,?) in the Attribute Method field.

•Click the grey button to set the input parameters datatypes. You are prompted to select the data type for each parameter:

Figure 7-43 Query Parameter type

•Select each parameter type from the drop-down list and click OK. This will close the pop-up page and take you back to the attribute source page.

•Attribute Returns—Select the return type for the new method.

Step 4 Click Save. This creates the new attribute.

You can create multiple attributes for this attribute source by clicking Add Attributes.

Application Attribute Source of Web Service Type

This is also called Webservice PIP. Using this feature you can use a web service as an external attribute source for database. This source contains all the Java methods that are exposed for a particular service. Further, these methods are used for creating attributes for the web service PIP. The PAP console allows you to create a web service PIP with or without enabling SSL. It supports only one-way SSL.

To create an attribute source of type web service under an application, you must:

Step 1 On the Application attribute source page, click Add attribute source. The attribute source Information page is displayed.

Step 2 Enter the attribute source name.

Step 3 Select Web service from attribute source Type list. This adds the Attribute Base Type section in the page.

Step 4 Select WebservicePIP from the Attribute Base Type drop-down list. This adds the Webservice-related fields, such as username, password, and URL.

Figure 7-44 Application Attribute Source of Web Service type

Step 5 Enter the Web service URL.

Step 6 Enter the Username and Password.

Step 7 (Ignore this step if you are creating the source without enabling SSL). To create a webservice PIP with SSL enabled, select Enable SSL from the drop-down list.

Note CEPM does not support configuring two-way SSL for web service PIP.

This will add truststore fields to the Create DataSource MetaData page.

•Trust Store password—Enter the keystore password.

•Trust Store Location—Enter the location of the SSL certificate. You can mention the absolute path or relative path of the certificate. For example, if you are providing the relative path, you must enter .keystore in the Trust Store Location field (ensure that the SSL certificate is copied in CEPM_HOME/config folder). Otherwise, you can enter the absolute path, for example, C:/test.cer.

Note If you are using https Webservice, then you must create .keystore using the SSL Certificate. To do this, you must:

–Download the SSL certificate (for example, test.cer) into your local machine.

–Import this file into the application by running the following command:
   JAVA_HOME\bin\keytool -import -trustcacerts -keystore .keystore -alias tomcat  
   -file D:\test.cer
–You are prompted to enter the keystore password.
    Enter keystore password: password
–The required .keystore file is created in the JAVA_HOME/bin folder.

–If you want to provide the relative path in the datasource metadata page, copy this file to the CEPM_HOME/Config folder.

Step 8 Encryption scheme: This scheme is used to encrypt the passwords that are parts of creating the attribute source, such as DB password, context password, and so on. You can select the default encryptor scheme pre-packaged with the CEPM application or can make use of your own scheme after integrating it with CEPM. In the above screenshot, Default Key has been selected as the encryptor scheme. Refer to the CEPM PAP Configuration Guide for more details on how to plug-in third party encryptor schemes.

Step 9 Click Test to verify the accuracy.

Step 10 Click Save. This creates a new attribute source in the attribute source page.

Adding Attributes to the Web Service Attribute Source

For the webservice PIP, you can create attributes only by using the operations available under that service. For example, if the webservice has an operation performed by an API called getDecisionByAttributeValue, you can use this API as an attribute for the webservice PIP.

To add an attribute to the new source, you must:

Step 1 Choose Home > Manage Entities > Application Attributes.

Step 2 Select the required attribute source (webservice PIP) and click Add Attributes.

The DataSource MetaData page is displayed.

Figure 7-45 Adding Attributes to Web Service Attribute Source

Step 3 Enter the following attribute metadata in this section:

•Attribute Name—Enter the name of the attribute to create.

•Attribute Method—Select the attribute method name from the drop-down list which contains all the java methods described within the selected webservice PIP. All these methods will be stored in the format methodName(?,?), where each question mark represents an input parameter to the specified method. For example, if the method add has three parameters, then it should be mentioned as add(?,?,?) in the Attribute Method field.

•Click the grey button to set the input parameters datatypes. You are prompted you to select the data type for each parameter:

Figure 7-46 Query Parameter type

•Select each parameter type from the drop-down list and click OK. You are returned to the attribute source page.

•Attribute Returns—Select the return type for the new method.

Step 4 Click Save. This creates the new attribute.

You can create multiple attributes for this source by clicking Add Attributes.

List Repositories

CEPM supports entitlement management while using multiple concurrent entitlement repositories that can be geographically distributed. This provides deployment flexibility to meet enterprise and compliance needs. For example, geographically isolated entitlement repositories for EMEA and NA can be supported with central, delegated visibility using the PAP SOAP.

In CEPM, repositories are entitlement domains within which a PAP user can exercise roles and controls. CEPM supports creation of more than one entitlement domain and assigns those to one or more PAP users. These entitlement domains are defined by the use of a separate entitlement repository or database for that domain. Support for multiple entitlement domains is very useful when there is a need to store entitlement data separately for such things as different geographies and application groups. Administrators can choose the entitlement domain they would like to log in to by selecting the appropriate domain in the drop-down list on the login page. By default, users are logged in to the default domain. Administrators can register additional entitlement repositories / domains.

Repositories contain aggregates of application groups, their subsequent applications, resources, and child resources along with corresponding policies in each domain. Considering as a distinct project, while creating a repository, substantial provisions have been made for creating, mapping, and defining users, resources, policies, and rules independently in order to make each of these constituents available on selection of the same repository during login.

Authorized users can create their own repositories apart from the default repository. Any repository so created is automatically listed in the default pool and is available at the time of login to all users. Only the owner or any delegated user can access the repository from the default pool. Creating repository is a special function, and the user needs to be entitled to perform this operation only through the Admin Entitlement.

To create a new repository, you must:

Step 1 Choose Home > System Config > Repository > Create Repositories. The Create/List Repository page is displayed.

Figure 7-47 List Repository

This page lists the existing repositories created by the current user.

Step 2 Click Create New Repository. The Creation of Repository page is displayed.

Figure 7-48 Create Repository Home Page

Step 3 Enter the repository name.

Note The entity names have a limitation of 100 characters and the special characters allowed are Dot(.), Underscore(_), hyphen(-), and asterisk(*).

Step 4 Select the database type from the drop-down list. The CEPM currently supports Oracle, MS SQL, and DB2.

Step 5 Select the connection pool. You can use either the pre-configured CepmConnectionPool or your own customized WeblogicConnectionPool.

If you select the CepmConnectionPool, a new section is added to the page.

Figure 7-49 Create Repository

Step 6 Enter the following database details and connection pool settings:

•Username—Enter the database username.

•Password—Enter the database password.

•URL—Enter the database URL (Host and port number of the machine where the database is running.)

•Driver—Select the corresponding database driver. Note that the database driver selected earlier and the database type must be correlated.

•Enter the Max Connection, which is the maximum number of users to be connected at any point of time. For example, if this number is set to 10, the application does not allow more than 10 admin users to log in to the repository.

•Enter the Max Connection Time, which is the duration up to which the database connection is alive.

•Enter the Idle Connection Time. If no transaction occurs during this time period (that is, the application becomes idle), the database connection is automatically shut down on the expiry of this duration.

If you select the WeblogicConnectionPool, a new section is added to the page.

Figure 7-50 Repository with Database details

Step 7 Enter the following database details and connection pool settings:

•Context Username—Enter the connection context username.

•Context Password—Enter the connection context password.

•Context URL—Enter the connection context URL (host and port number of the machine where the database is running).

•JNDI Name—Enter the JNDI name for the data source.

For more information on how to configure a WebLogic connection pool, refer tothe CEPM Installation and Configuration Guide.

Step 8 Click Create. This displays the completion status bar indicating the complete and consistent execution of the task.

You are returned to the Create/List Repository page and the newly created repository is listed in the repository table. When you re-login to the CEPM environment, you find this new repository listed in the Entitlement Domain drop-down list.