Securent Entitlement Management Concept Guide › c › dam › en › us › td › docs ›...

Securent Entitlement Management Solution

Concepts Guide

September 2007

Part Number: 31GA-CONC-01

Copyright Copyright © 2006-2007 Securent, Inc. All Rights Reserved. Restricted Rights This software and documentation is subject to and made available only pursuant to the terms of the Securent Inc. License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior consent, in writing, from Securent, Inc. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND INCLUDING, WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, SECURENT DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.

Table of Contents Introduction____________________________________________________________________ 1 Document Overview ___________________________________________________________ 1 Additional Information __________________________________________________________ 1 Note on Document Syntax ______________________________________________________ 1 Overview ______________________________________________________________________ 2 Entitlement Management Using Securent ________________________________________ 2 Physical Architecture ___________________________________________________________ 3 3-tier Entitlement Management Model___________________________________________ 3 Securent EMS for Hybrid Environments ___________________________________________ 4 In-process and Out-of-process PDP ______________________________________________ 5 Entitlement Repository Deployment Options______________________________________ 5 Caching Model ________________________________________________________________ 7 Failure Model __________________________________________________________________ 7 Global Multi-domain Deployment Model ________________________________________ 8 Entity Model____________________________________________________________________ 9 Overview ______________________________________________________________________ 9 Subjects _______________________________________________________________________ 9 Resources______________________________________________________________________ 11 Policies ________________________________________________________________________ 12 Policy Model ___________________________________________________________________ 14 XACML Policy Model ___________________________________________________________ 14 Assignment of Permissions to Roles_______________________________________________ 15 Hierarchical RBAC ______________________________________________________________ 15 Assignment of Roles to Subjects _________________________________________________ 16 Scoping of Roles _______________________________________________________________ 16 Contextual Assignment of Roles _________________________________________________ 16 Delegated Administration_______________________________________________________ 17 Delegated Self-Administration for Multi-Tenant Applications _______________________ 17 Product Architecture and APIs___________________________________________________ 18 Typical IT Stack _________________________________________________________________ 18 Java PEP_______________________________________________________________________ 18 .NET PEP _______________________________________________________________________ 19 Administration APIs _____________________________________________________________ 19 Decision APIs___________________________________________________________________ 20 Extensibility Interfaces___________________________________________________________ 21 Administration-time extensions __________________________________________________ 21 Pre-hook_______________________________________________________________________ 21 Importing/Exporting Policies _____________________________________________________ 22 Decision-time extensions ________________________________________________________ 22 Custom Attribute Sources _______________________________________________________ 22 Custom Listener Framework _____________________________________________________ 22 Custom Authentication _________________________________________________________ 23

Securent EMS Concept Guide

Introduction Document Overview This document describes the basic concepts that are embodied in the Securent Entitlement Management Solution (Securent EMS). The document is divided into five main sections:

1. Overview: The first section describes the high-level concepts embodied in Securent EMS, what its basic capabilities are, its main architectural components, and its general model for managing, evaluating, enforcing, and auditing application entitlements.

2. Physical Architecture: Here we touch upon the salient aspects of the physical architecture and deployment model.

3. Entity Model: The third section describes the entities modeled in Securent EMS (such as subjects, resources, and policies), the relationship between these entities, and the beginnings of the policy model.

4. Policy Model: The fourth section describes the policy model in detail including the Role and Rule based policy model, descriptions on how Securent EMS handles scoping of roles, dynamic rules, and other advanced policy model concepts.

5. Product Architecture and APIs: The last section describes the Securent EMS product architecture, including the various APIs, component communication and protocols, and utility functions/tools that enable easy integration with both decision and administration functionality. The stage is set with an in depth look at how Securent EMS fits into the typical IT stack.

Additional Information This document should be used in conjunction with the following documents that describe the product use in more detail:

- The Securent Users Guide - The Securent Developer Guide - The Securent Deployment and Capacity-Planning Guide

Additional information can also be found in the tutorial / sample material shipped with the product.

Note on Document Syntax All terms that apply to objects used in Securent EMS are capitalized or bold throughout the document. If you do not understand the definition of a term which is capitalized or bold you will find it in an earlier section of the document.

Proprietary and Confidential 1


Overview Entitlement Management Using Securent

The Securent Entitlement Management Solution is a unique, scalable, enterprise-ready solution for achieving fine-grained distributed entitlement management, resolution, enforcement, and auditing. Securent EMS is a paradigm shift from traditional, tightly-coupled, and brittle application entitlement systems to a multi-tiered, loosely coupled, and standards-based entitlement model consisting of:

1. A centralized and/or distributed Policy Administration Point (PAP), 2. high-speed, centralized and/or distributed Policy Decision Points (PDP), and 3. pre-built or customizable, optimized Policy Enforcement Points (PEP)

Centralized Entitlement Administration & Audit Using Policy Administration Point Securent PAP provides centralized administration, management and monitoring of entitlement policies, with delegation and integration with an entitlement repository. The Securent PAP enables disparate and centralized teams to author policies and access the auditing and reporting functionality. Distributed Policy Resolution Using Policy Decision PointSecurent PDP provides evaluation of application-specific and enterprise authorization policies. Securent PDP also connects with existing policy information repositories, e.g., LDAP, databases, etc., that are referred to as Policy Information Points or PIPs.Externalized Enforcement Using Policy Enforcement Point Securent Policy Enforcement Points (PEPs) enforce entitlement policy decisions made by the Securent PDP for applications, frameworks, and resources.



Physical Architecture 3-tier Entitlement Management Model

Securent EMS has a 3-tier logical architecture as depicted below. Depending on the deployment model and the specific physical architectures of the applications that Securent EMS is securing, the Securent EMS components (PEP, PAP, and PDP) sit at various network tiers (although still following the 3-tier architecture between the components). In this section we will go through some examples of various Securent EMS deployment models and relate this back to the 3 tier architecture model of Securent EMS and the architecture model of the applications being secured for the various scenarios.

Entitlement repository

PAP

PDP

PEP

Application

In general a 3-tier model has a presentation tier, an application tier, and a data tier. Logically, the PEP is in the presentation tier, the PAP and PDP are in the application tier, and the Entitlement Repository is in the data tier. Physically the architecture can take on many forms to secure applications with varying architectures, which is one of the product’s strengths. Below are some

of the highlights of this flexibility for each Securent EMS component.

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

• The PDP, similarly, can be placed in any tier to resolve entitlements for the applications or application components running in those tiers; although 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 subsection below entitled “In-process and Out-of-process PDP”.)

• The PAP is generally placed in the application tier as a J2EE web application and hence takes on the architecture of a J2EE web application – web server serving up the html for the PAP in the presentation tier, J2EE application server running the PAP application, and Entitlement Repository in the data tier. The PAP, or PAP functionality, can also be run from within custom applications which may run in other tiers, see section entitled “Product Architecture and APIs” for more information on this scenario. The PAP can also be run in any physical or network tier.

• The Entitlement Repository is a database and is where all of the Securent EMS policy, resource, and role definitions are persistently stored. The Entitlement Repository is generally always in the data tier of the networks into which it is deployed.

Securent EMS for custom, home-grown applications The combination of Securent PAP, PDP and PEP provide the most comprehensive solution for externalized policy and role-based entitlement management for custom applications implemented in Java, .NET or COM. In this case, the Securent PAP is used to model policies that are persisted in an entitlement repository. Policy updates are communicated by the PAP to the appropriate PDP in real-time. PDP uses these updated policies at run-time for authorization decisions.



The PEP (Java, .NET and COM) intercepts application requests and queries the PDP for policy decisions. No authorization related logic is implemented within the application. Policy lifecycle can be managed either via the Securent PAP UI, or by integrating the Securent PAP functionality into custom admin applications using the PAP SOAP interface.

Securent EMS for COTS applications

Entitlement repository PAP

COTS Application

Custom

Application-native

DB writes, or Application

Legacy and COTS applications (such as Documentum, CRM systems, etc.) may already have entitlements built into the application. In these cases, it will be impractical or difficult to completely externalize run-time policy decisioning from within the applications. In the case of COTS applications, it may not be possible, or necessary, to involve the Securent PDP and PEP in run-time policy decisions. Instead, the Securent PAP would be used for externalized administration of entitlements, providing greater control and visibility for administrators to author and change policies in real-time, while at the same time enhancing auditing and compliancy. In this deployment model, all policy changes are updated, from the PAP, in native form to the applications so they can continue to use their native security mechanisms at run-time. This is achieved in Securent, via the configuration of custom policy-

handlers at the Securent PAP. These policy-handlers will convert administration events to application specific calls or DB entries that result in user, group or Role based ACLs or access control rules. The PAP DB acts as a central authoritative repository of entitlement policies that can be queried against for audit and review. In addition, policy lifecycle can be managed via the API and UI supported in the product.

Securent EMS for Hybrid Environments

4

Entitlement repository

PAP

COTS Application

Custom

Application-native ACLs / policies

DB writes, or Application APIs

PDP

PEP

Application

The unique features of Securent’s entitlement administration capability can be simultaneously applied to both custom applications protected by Securent PDPs/PEPs as well to applications that rely on their native security mechanisms. This is achieved by supporting:

- a metadata model that captures the relationship between applications/ resources and the authoritative PDP

- all PAP-based entitlement policy changes

that virtualize PDP identity by allowing entities such as Subjects, Resources and Attributes to be used for policy authoring. This allows migration of PDPs from one model to another over time without change in policies (for example, a move from a legacy entitlement engine to a Securent PDP will not need any change in policies)



- capability to add multiple custom adapters to write out policies in native format via

APis, DB access etc. simultaneously. In this model policy changes are captured via an appropriate interception callout in the PAP that is configured to talk to one or more external policy handlers over any custom/standard protocol

- ability to consistently author and review policies centrally via the PAP even if

policies are enforced/resolved in native form at various PDPs

In-process and Out-of-process PDP

PAP

PDP PDP

PDP

serverserverserverprocessprocessprocess

CachingPEP

PDPs can either run:

a. out-of-process (in the same server or on a separate server) from the application in which the PEP executes, or

b. can be deployed as a library to run in-process with the application, along with the PEP.

In the out-of-process case the PEPs interact with the PDPs via TCP-based communications (e.g. XACML / HTTP) while in the in-process case PEPs simply make library calls eliminating network latencies. The PAP can be used to centrally manage policy lifecycle independent of the deployment model chosen for the PDPs. Both the in-process and out-of-process PDPs share the same code and perform similar functionality. The out-of-process PDP is deployed as a WAR file in any servlet container, while the in-process PDP is deployed as a jar file along with the PEP jar. For .NET applications, the .NET PEP is implemented natively in C#, while the PDP can be deployed to run in the same CLR instance via the use of 3rd party .NET-Java bridges.

Entitlement Repository Deployment Options An Entitlement Repository holds all the meta-data required to administer the entitlements for an application as well as for evaluation of policies. Entitlement Domain is a view into an Entitlement Repository. The Policy Administration Point (PAP) provides a view into the repository and is responsible for persisting all the meta-data into the repository. A user can choose to work with one of the domains available from with in the PAP. In each domain, there are two models for sharing entitlement policies between the PAP and the PDP.

1. Shared Repository Model – In the shared model both the PAP and the PDP share a common Entitlement repository (the repository itself can be deployed in a HA,



clustered environment). The PAP will be used to administer all the entitlements which will be persisted to the repository being used (called Entitlement Domain). The PDP accesses the same repository to evaluate the policies and give the decisions. In this model there can be one instance of the PAP communicating with several entitlement repositories. Each of the PDPs will communicate with only one entitlement repository. The below figure illustrates this.

2. Distributed Repository Model – In this model, the PAP and the PDP use their

own repositories. In this model the PAP and PDP communicate using a messaging infrastructure. The PAP has support for handlers and these handlers will publish every action in the PAP to the messaging server. The PDP acts a subscriber and consumes the messages. The subscriber at the PDP end is also responsible for persisting the data into its own repository.

a. Entitlement Authority

The Entitlement Authority or the PAP has its own repository and changes to the entitlement data are stored in this repository. The PAP has Pre-Handlers which are invoked for each and every action within the PAP. The handlers are configured to publish each and every action along with the data to a messaging server. Essentially the handler acts as a publisher of a message with the entitlement data as the payload to the messaging server. The handler will not persist the entitlement data to the repository in cases where the messaging server is not available.

b. Consistency between Entitlement Repositories Consistency between the entitlement repositories, used by the PAP and PDP is accomplished by having a reliable message delivery between the two repositories by making use of the messaging infrastructure. The PAP also provides a way to synchronize the entitlement data between the two repositories. When synchronization needs to be done between the PAP repository and the PDP repository the PAP again makes use of the messaging layer to send the entitlement data to be synchronized to the PDP repository.

c. Reliable Delivery Reliable delivery is achieved by configuring the messaging server to persist the messages. Although the messaging infrastructure itself guarantees delivery, it can be further configured to persist the messages to take care of



situations where the PDP is down. In cases where the PDP is running but the repository is not available, the PDP sends a message back to the publisher to roll back the changes done. This will further ensure that the consistency of data is maintained between the two repositories.

Caching Model Securent components support a sophisticated caching, pre-fetching and policy propagation model. Policy changes made via the Securent PAP are communicated to the relevant PDPs (independent of whether or not there is a shared repository between the PAP and PDP) as indicated in Step 1 in figure below.

PAP PDP PEP2

PDP decision cache

PEP decision cache

PEP1

1

2 3

3

The PDP keeps track of policy updates the PDP decision cache with re-evaluated policy decisions, as indicated in Step 2. The PDP decision cache contains the most recent, updated decisions for Resources. The PDP’s decision cache acts as the master and policy changes are propagated to the PEP caches via a pluggable, reliable messaging infrastructure (such as JMS or MQ), as indicated in Step 3. An alternative pull-based model enables PEPs to periodically poll the PDP for any change in decisions; any changes in decisions are then updated by the PEP in its local cache. Additionally, the PEP caches can be configured to persist policy decisions in a database or file system. The net effect of this architecture is that policy changes made in the central PAP result in near-real-time update of decision caches at the PEPs running with the applications in a reliable manner.

Failure Model Securent has been designed to have no single point of failure. The PAP (that can itself be deployed in a J2EE cluster) is not involved in run-time decision making and hence even if the PAP (or PAP cluster) goes off-line, the run-time decision infrastructure will continue without impact.

1. If the entitlement repository goes off-line, the PDP will continue to function with the cached policies; the impact of repository failure is restricted to inability to persist updated policies from the PAP until the repository comes back on-line.

2. If the PDP (or the PDP cluster) goes off-line, the PEP will seamlessly and automatically failover to an alternate instance of the PDP over a wide-area.

3. If none of the PDPs are reachable, the PEP can continue to work off of the decision cache that is local to the application. As soon as connectivity is established with the PDP, any updated policies since the last known time of connection with the PDP is communicated by the PDP to the PEP.

4. PEP cache can also survive application recycles as the PEP cache can be configured to be persisted in local store.

With the combination of the above four features, any failure is isolated and does not have system wide effects that can result in disruption of application function.



Global Multi-domain Deployment Model Note: This is a more advanced deployment model which we cover, along with others, extensively in the “Securent Sizing and Distributed Deployment Guide” whitepaper. We have included one such deployment here to give you an example of what is possible. If you are interested in more complex deployments like this, please read the whitepaper we have dedicated to the subject.

In this deployment option, even the PAP is not shared across geographies. Each geography deploys its own instance of the PAP which persists the entitlement data locally. The PDPs connect to the local entitlement repository and hence do not require any messaging directly with the PAP.

Policy updates performed in one PAP (using the Securent PAP GUI, or PAP APIs) will automatically result in an event that is published to other peer PAPs that are distributed geographically over a highly-available MOM infrastructure. Alternatively, custom persistence layer mechanisms can also be used to automatically persist and replicate data across multiple repositories.

In all of the above cases, PEPs can be configured to failover to alternate instance of PDPs across geographies. So, in cases where a local clustered deployment of PDPs (out-of-process) is unreachable, the PEPs will automatically failover temporarily to other instances of the PDP. PDPs can be deployed so that they can be load-balanced (round robin) within geographies.



Entity Model Overview Policy-based application entitlement ensures that a Subject accessing a Resource (or invoking an Action on the Resource) is allowed/denied based on Policies. Securent’s data model reflects this approach and consists of three basic constructs: Subjects, Resources and Policies. Each of these are typed and hence extensible enough to describe policies in varied heterogeneous environments.

Resourceaction

Subject Policy(allow/deny)

In this model, each Subject (such as a user) represented by a set of Attributes (such as Name, Group, etc.) accessing an Object (such as an application, transaction, document, portal resources, etc.) represented by a set of Resource Attributes (such as Document Name, Document owner, etc.) is protected by policy that encapsulates rules that reference Subject, Resource, Message and other contextual Attributes required for decision resolution.

User, App, etc. Groups Resource

Groups

Resources

Member of

Policies

Attributes Attributes

Roles

Subject Resource

Rules

Member of

Attributes

Attributes, Actions

Subjects Subjects are associated with a mandatory Subject identifier attribute used to identify the subject on whose behalf run-time policy decisions are made. Subject identifiers are typically the authenticated identity of a user or application accessing the Resource. This authentication is typically done outside of the scope of Securent EMS.



User

Application

0..*

-users

0..*

UserType

UserType()

1

-userType

1

-userTypes

ApplicationGroup0..*

-applications[]

0..*

<<include>>

0..*

-users

0..*

-userTypes

0..*0..*

AttributeAbstractType #attributes[]

0..*0..*

Essentially, Subjects have the following characteristics:

- Subjects are uniquely identified within the context of applications or application-groups via the Subject-Identifier that is the run-time identifier on whose behalf an authorization decision is desired

- Subjects can be people, applications, devices, etc. each with its own type of attributes that identify the appropriate Subject. For example, an Employee subject type may be a subject with the attributes first name, last name, email, phone number, location code, and organization code, whereas a Customer subject type may be a subject with the attributes first name, last name, email, phone number, customer code, and employee sponsor.

- Securent supports the notion of a Subject-type that enables customer-specific addition of application-specific Subject attributes. Any Subject can be declared to be of a particular Subject type and automatically the Subject is associated with the attributes. Default values for attributes can be set during creation of Subject types.

- The authoritative source of Subjects can be external and independent of the Securent product (such as an enterprise LDAP, Active Directory, Database, etc.) without need for replicating the data in Securent EMS.

- Some Subject attributes that are typically non-application specific can be managed in an external User-directory while other Application-specific Subject attributes can be managed within the Application-related metadata managed within Securent. Subject attributes referenced in policy can be a combination of both user-directory and application-directory attributes.



Resources A Resource is any protected entity whose access needs to be secured by policy. Resources can apply to a diverse set of real word things. Below is a list of things that Resources are typically used to model:

- Physical resources: Documents, files, mutual funds, insurance claims, stocks, binds, servers, network devices, and networks.

- Web components: Buttons, links, web pages, portlets, etc.

- Application objects: Methods, classes, beans, data types, etc.

- Transactions: Trades, instant messages, and transaction server and messaging service communication such as JMS or MQ Series topics or messages.

- Data: Physical data records or files, database rows or columns, and database functions or procedures.

This is not an exhaustive list and there are certainly other examples of Resources such as business units, geographical locations, people, network segments, etc.

Resource0..*

#children

0..*11

-parent

Application

0..*

-children

0..*

ResourceType

ResourceType()

0..*

-resourceTypes

0..*

AbstractResource

#resourceType

11

Attribute

AbstractType

#attributes[]

0..*0..*

Resources have the following characteristics:

- Resources are uniquely identified within the context of applications or application-groups via a fully qualified name (FQN) that is the run-time identifier of the target resource being protected by policy. For example, ‘Application Group Name:Application Name:Resource Name 1:Resource Name 2: … :Resource Name n’ is a typical FQN for a Resource.

- Resources can be typed and can represent diverse types such as portals, documents, devices, buttons, transactions, chat sessions, etc. Each Resource Type is identified by a combination of a collection of Attributes that identify the appropriate Resource. For example, a document Type may contain attributes such as: Document name, Author name, date, sensitivity level, etc. In addition to attributes, Resources are also associated with zero or more Actions that can be invoked on a Resource. In the document example, there may be 4 valid Actions: Read, Write, Open and Close. A Resource of Document type can be protected as a whole or each individual Action can be protected. In any case, anytime a Resource of a particular type is created, the Resource gets automatically associated with Attributes and Actions that can be set appropriately for that Resource.



- Some Resource attributes may be managed in an external data-store while other Resource attributes may be managed as Resource Attributes described above. External Application-related attributes can be associated with Applications or Application groups and can be referenced in policy.

Resources can be secured as a whole or by individual Actions that can be performed on the resource. For example, if a document is the protected resource on which Read and Write actions can be performed, then protecting the named action will leave the other actions unprotected. Protecting the entire resource will protect all actions that can be performed on the resource even if they are not predefined. By default, Resources that do not have an “Allowed” policy for a Subject (either explicitly or via inheritance) are denied access to resource / action.

Policies Policies in Securent are rule and role-based and are flexible enough to handle varying granularities of authorization. A spectrum of policies from simple application-specific role-based access control of portals, to dynamic, rule based Separation Of Duties (SoD) policies during collaboration are handled in a consistent and easy-to-use manner. The policy model provides a rich hierarchical model of resources, subjects, obligations and actions in line with industry standard terminologies and authorization models such as RBAC and XACML. Targets Resources, Actions or Subjects are protected by a set of one or more Policies (called PolicySets). Conflicts between policies in a PolicySet are resolved via policy combining algorithms (for example, Deny-overrides, Permit-overrides, etc.). (Policy combining algorithms are explained in detail below.) A Policy in turn contains one or more rules that support a rich condition-effect syntax enabling the expression of complex rules in a standards compliant manner. Details of the policy language can be found at http://www.oasis-open.org/committees/xacml/

PolicySet

Policy Combining Algorithm

Target ObligationsPolicy

Subject Resource ActionRule

Combining Algorithm

Rule

Effect

Condition

1..*

1

1

1

0..11

1..*

1

1..*

1

0..*1

11

0..1

1

0..1

1

0..1 10..*

10..*

1

1

10..*11

1

In addition to returning a decision, the entitlement engine returns one or more “Obligations” to the PEP. Obligations allow the PDP to communicate certain requirements/constraints that the PEP should follow while using the decision. For example, an Allow decision may be communicated to the PEP but with the constraint that the PEP is obliged to log the request, or add certain attribute values in the session cache, etc.


http://www.oasis-open.org/committees/xacml/


Policy Combining Algorithm: I. Deny-Overrides: If the resource has a single Deny policy irrespective of the number of Allow policies, then the result of the Rule combination shall be Deny. So, if this rule is selected, the Deny policy overrides all the Allow policy granted to that particular resource. II. Permit-Overrides: Likewise, selecting this rule, the Allow permission overrides all other permissions granted to the policy. III. First-Applicable: This rule considers the way policies are listed for a resource. Applying this rule enables the application to choose the very first policy granted to the Role. IV. Only-One-Applicable: When there is only one policy for a resource, the algorithm will evaluate the same whether Allow or Deny. If there is more than one policy, it will evaluate to indeterminate. V. Lower-Role-Overrides: This rule uses the decision for the lowest role in the Role hierarchy. V. User-Based-Overrides: On selecting this rule, the PDP will override the user-based policies created for the specified user while giving decision on the basis of Role-based policy.



Policy Model XACML Policy Model Policies are normalized into the XACML model in Securent. A decision query request to the PDP consists of attributes associated with the requesting subjects, the resource acted upon, the action being performed, and the environment. A response contains one of four decisions:

• permit, • deny, • not applicable (no applicable policies or rules could be found), or • indeterminate (some error occurred during processing). In the case of an

error, optional information is provided to explain the condition. Responses may also include obligations, which are directives from the applicable policies which the PEP is obliged to execute.

PolicySetObligations

Target

PoliciesObligations

Target

Rules

Target Condition

Effect

Rule combiningalgorithm

policy combiningalgorithm

XACML policies consist of an arbitrary tree of sub-policies. Each tree represents a target, while the leaves of the tree contain a collection of rules. The target is a simple set of criteria (on Resources, Subjects, Actions or Environment) to determine a policy's applicability to a request, while the rules contain more complex logic that makes XACML extremely expressive, and therefore able to handle complex policy requirements.

In addition to expressing access control logic within a single policy, policies can include references to other policies. This abstraction achieves the goal of modularly building complex policies while also providing a mechanism to handle policy conflicts. In effect, a single policy can consist of any number of decentralized, distributed rules, each managed by different organizational groups. A key supporting language feature is XACML's use of combining algorithms, which define how to take results from multiple rules or policies and derive a single result. As with datatypes and functions, there are a number of standard combining algorithms defined (first applicable, deny overrides, etc.), as well as a standard extension mechanism used to define new algorithms.

Policies depend on getting access to attribute values associated with Subjects, Resources, etc. Two mechanisms are used to resolve attribute values within policy logic:



AttributeDesignators (which reference values by identifier, datatype, and other optional meta-data), and AttributeSelectors (which use XPath expressions to find values). The PDP can access external attribute values via pluggable data access modules. Policies are created via a two step process:

1. Define the collection of permissions associated with a Role (application, Application-group or enterprise-wide)

2. Decide either statically or dynamically (at run time) which users are associated with what Role

A variation to the above steps allows one to directly associate rule-based policies for users or groups or users without explicitly defining Roles. In either case, the underlying policy resolution logic in Securent works exactly the same way.

Assignment of Permissions to Roles In many situations, the end result of policy evaluation at run-time, is an allow or deny decision for a specific Subject based on the Subjects’ membership in a Role. In this context, the collection of privileges (both positive and negative) associated with a Role are modeled in Securent EMS resulting in an access control matrix of the form below. An access control matrix such as this is helpful in determining (or modeling) permissions on paper before attempting to build the model in Securent EMS.

Task Add View Search Analyze Trade View All

Admin Tasks

Escalate To

Role Member a a Owner a a a Submitter a Trader a a Admin a Super User a

Hierarchical RBAC There are three common approaches used for hierarchical RBAC: tree, inverted tree and lattice. Securent supports the inverted-tree and lattice models (the tree and inverted-tree model are functionality equivalent and there is no need to support both). Inverted tree model enables higher-level roles to add to privileges that may be granted to lower-level roles. For example, a project lead has all privileges of a production and quality engineer in addition to privileges assigned to project leads. A lattice model is also supported in Securent via the capability to reference roles while creating a role hierarchy, and support for multiple inheritance.



Inverted tree (b) and lattice (c) role models

Assignment of Roles to Subjects Subjects can be statically assigned to roles via explicit assignment or a Subjects’ association with a Role can be determined via dynamic evaluation of rules / policies at run-time. Securent EMS supports both a static and dynamic approach for Role assignment. Roles determined via dynamic evaluation of rules / policies at run-time are called a Dynamic Role within Securent EMS. Examples of Dynamic Roles include assigning subjects with the attribute employee to the Employees role or assigning subjects with an account balance of greater than $100,000 to the Platinum Trader role.

Scoping of Roles In many situations the Resources or attributes of a Resource to which the Role grants access must be limited (or scoped). In this case there are certain attribute values of the Resource. This acts as a means to scope the privileges of a Subject. For example, a Subject (say Joe) may be associated with a WiresAdministrator Role, but only for accounts with the location attribute set to California. Attributes associated with Subjects, Resources and Roles can be used to scope the Role in Securent EMS to achieve this effect. Additionally, Securent allows users to choose the relevant scope attributes as well as entity attributes that need to be returned back to the application for further processing.

Contextual Assignment of Roles A Subject is not typically provided blanket set of privileges. Instead, Subjects are typically assigned different set of Roles in different contexts. For example Joe may be associated with WiresAdministrator and WiresUser Roles during work hours, but may be associated with the WiresUser Role after-hours. This capability to contextually assign a set of Roles to Users is accomplished in Securent with the use of “RoleBundles” – providing a convenient mechanism to assign users to a collection of Roles that are assigned in different contexts.



Delegated Administration Since there are multiple Applications, Resources and Groups of Subjects that are all being managed from the same administration environment, there is a need to allow delegated administration of these entities. Securent supports the capability to delegate administration up to an individual Resource level, as well as individual Subject Group level enabling multiple administrator ownership even within the same User population and Application.

Delegated Self-Administration for Multi-Tenant Applications In addition to delegated administration of Resources and Groups, for applications that are hosted in a multi-tenant model, wherein an application is offered as a Service to multiple partners/customers, there is a need to create the notion of a hierarchical delegated context allowing autonomous delegated control to administrators to create mappings of Subjects to Roles, and association of privileges to Roles. This model supports a default context in which Roles and their associated privileges are defined, and allows delegated administrators to inherit / override these default mappings and privileges for their domain is supported in Securent via the “Context” construct.



Product Architecture and APIs Typical IT Stack Securent allows externalized policy-based entitlement of Resources at various layers in the IT stack. Four common layers where entitlements are required are shown below.

Presentation(Web)

Biz Process

Component logic(app)

Data access

Presentation layer:Control of display of buttons/tabs etc. at web-app or portalEx.: Securent Taglibs for webapps,

Securent portal agents (Sharepoint, J2EE, etc.)

Business process layer:Control of tasks and process execution based on process stateEx.: Securent agent for web-services, BPM

Component logic layer:Control of Java/.Net method invocationsEx.: Securent agent for j2ee/.Net applications

Data access layer:Control of what data is returned from database queriesEx.: Agent for data filtering at OR / DAO layer; or at DB server

Securent’s 3-tier architecture enables codeless protection of Resources in all the above tiers via agents. These agents typically intercept messages at the container-level and enforce policies with the use of the Securent PEP. In these cases developer involvement is minimal (if any) and is largely confined to configuring the appropriate container-specific configuration files. However there are situations where Resources that are not container managed, or Resources that require protection via code need to resort to making API calls such as “isUserAuthorized()” calls. Such APIs for decisions are supported via the Securent PDP APIs. Similarly there are applications that need to make API calls for administration such as to grant/revoke user privileges, query available Resources, etc. Such administrative calls are supported via the Securent PAP APIs. Both PDP and PAP APIs are supported via packages in Java, .NET, and COM-based libraries.

Java PEP Securent supports a Java PEP in the form of a jar file. This library exposes APIs that can be directly invoked from any java based application. This is also the library which is used by container-specific agents for enforcing policies at the container level. Please refer to the Javadocs for a details about the APIs supported. The Java PEP supports Java libraries for both decision and administration APIs.



.NET PEP

.NET based applications can be entitled using Securent PEP for .NET. The agent is a DLL which can be made use of by any .NET based application (either a desktop or a web based application). A COM-wrapped agent is also supported for VB, C++ and other Windows-based applications. As with the Java PEPs, the .NET PEP supports libraries for both decision and administration APIs. Please refer to the ‘Securent Entitlement Solution For Dot Net’ document for more detailed instructions on usage of APIs as well as deployment. The two packages of interest are:

1. Policy Administration Point (PAP) API 2. Policy Decision Point (PDP) API

PAP PDP

Application (custom scripts or

entitled applications)

Custom Admin UI

PAP API

(Decision queries to PDP) (Administrative

calls to PAP)

XACML SOAP Other SOAP

The above packages are intended to be used for customization and easier integration of the Securent components with customer deployments. The following three categories of functionality are supported:

- creation of custom administrative consoles [use the PAP APIs] - invocation of decision queries from applications [use the PDP APIs] - run-time queries to the PAP for creation of automated scripts or policy queries from

applications [use the PEP APIs]

Administration APIs The PAP API helps in accessing a broad set of functions which are enabled through the PAP UI. You can make use of these API to create your custom UI or to write scripts which make creation of users, roles, applications etc a lot easier rather than to create them using the UI one at a time. A non-exhaustive list of the various functions that supported by the PAP UI and the SOAP APIs (accessible via the .NET and Java APIs) is listed below



• Application Groups / Applications o Create o Update o List o Delete

• Resources / Actions

o Create o Update o Delete o List o Assigning resources / actions to application o Assigning a application to application group

• Users / User Groups / Roles

o Creation of users, groups and roles, and their types o Updating of users, groups and roles, and their types o Deleting of users, groups and roles, and their types o List of users, groups and roles, and their types o Searching of users, groups and roles o Mapping of users to roles o Mapping users to groups o Assigning roles to groups

• Attributes o Create and assign Attribute Sources o Define Attributes o Configure Attribute Source caching and other properties

• Policies (Role and Rule based)

o Create o Update o Delete

• Review and Audit o Search / List Admin logs o Search / List Decision logs o Review SoD violations o Review User/Group and Role-based Resource entitlements

• Administration o Creation of trust model between components o Setting for PDP failover o Delegation o PAP entitlement

Please refer to the Javadoc documentation for more info on various methods.

Decision APIs Securent PEP Interface provides the methods for checking the whether the user is entitled to access a given resource/action in the Policy Enforcement Point (PEP). This interface also provides two utility methods, which return back a list of permissible resources for a given user and a list of permissible actions for a given resource.

A non-exhaustive list of APIs supported by the PDP APIs include:



o Check for access to a given resource/action for a particular user by passing subject, resource, action

o Check for access to a given resource/action for a particular user by passing subject, resource, action, attributeMap (when the custom attributes are passed), RoleBundles and Contexts

o Get a list of permissible resources for a given user o Get a list of permissible actions for a given resource o Get a list of Roles for a given resource

Extensibility Interfaces In addition to the PAP and PDP APIs, Securent allows on-the-field extensibility to customize various aspects of the policy infrastructure. These extensibility APIs can be broadly classified into:

1. Administration-time extensions 2. Decision-time extensions

PolicySet

PolicyCombining Algorithm

Target ObligationsPolicy

Subject Resource Action Rule Combining Algorithm

Rule

Effect

Condition

1..* 1

1

1

0..11

1..* 1

1..* 1

0..*1

11

0..1

1

0..1

1

0..1 1 0..*1

0..*

1

1

10..*11

1

PIPAttribute1..*

1•Extensible Subject, Resource and Action types

•Subjects and Resources are hierarchical

•Referenced via FQN

•Custom policy combining algorithms

•Custom obligations to control

•PIPAttributes reference attributes in its namespace

•Attributes can be restricted to be visible only within selected domains

•Used to define policies

Administration-time extensions These extensions allow administrators to extend the functionality of the PAP. PAP extensions include capability to convert Securent policies to legacy formats that can be enforced natively within COTS/legacy applications, and import/export of policies into Securent.

Pre-hook Securent supports the notion of pre-hooks which can be used to initiate a work flow from within the Admin Console or the Policy Administration Point(PAP). In addition to workflows, pre-hooks can be used as a means to allow Securent PAP to be used for policy authoring and review even when policy decisions and enforcement happen outside the scope of a Securent PDP/PEP. All administrative actions are configure-ably intercepted by the pre-hook handlers and appropriate actions can be triggered (including writing out policies in legacy/native forms). The interface for pre-hook is shown below. public interface IHandler {

public void init(Properties props); public void handle(Object policy,ActionEvent action)throws HandlerException; public void rollBack(Object obj[] , ActionEvent action[]);



public void rollBack(Object obj , ActionEvent action); } The IHandler interface also exposes a rollback method that can be implemented to handle error conditions that require rollback previously handled policy events.

Importing/Exporting Policies Securent allows import/export of policies via XML-based files both via APIs and via the PAP UI. Additional utilities have been built to directly convert MS Excel spreadsheet-based entitlement information into policies within Securent.

Decision-time extensions These extensions allow the PDP functionality to be extended by allowing plugging in of custom Attribute sources, or plugging in custom listener frameworks.

Custom Attribute Sources Attribute sources are used to get additional information from an external source which will be made use of in policy evaluation. Securent supports the following attribute sources out of the box – LDAP, AD, Database and a Java source. There are two parts to adding a custom attribute source – one, to add it to the admin console or the PAP and two, to make sure that the decision engine or the PDP is able to evaluate it. Adding a new attribute source to the admin can be accomplished by adding a XML file which defines the meta-data about the attribute source to be added. The meta-data might contain information about how to connect to the source etc. The second part is to let the decision engine make use of the implementation of the interfaces defined below so that the attributes can be evaluated and their values made use of in the decision process.

public interface IAttributeEvaluator { Public Object evaluate(IAttribute iAttribute,IPIPMetaData pipMetaData,IXacmlContext xacml,IRule rule,Rules rules)throws Exception; }

The above interface needs to be implemented for the PDP to get the attribute values.

Custom Listener Framework The Custom Listener Framework provides a way to add additional transport protocols for communication between the PEP and PDP. By default Soap over Http, XACML over Http and RMI are supported out of the box. If a protocol which is not supported out of the box needs to be added, it can be done so by implementing the following interface.

public interface ITransportAdaptor { public void init(PdpObject pdpObj); public Object send(XacmlRequest request)throws Exception; public PdpObject getPdpObject(); }



Custom Authentication The admin console or the PAP and the decision engine or the PDP authenticate the users before the two components can provide services. Securent by default supports authentication against its entitlement repository or against a LDAP. To plug in custom authentication providers like JAAS for example, the following interfaces need to be implemented.

public interface IAuthenticator { public boolean authenticate(String username, String password); public List getRoles(String username); public boolean isSuperUser(String username) ; } public interface IAuthProvider { public IAuthenticator getAuthenticator(Properties props) throws Exception; public IAuthenticator getAuthenticator() throws Exception; }


Securent Entitlement Management Concept Guide › c › dam › en › us › td › docs ›...

Documents

Transcript of Securent Entitlement Management Concept Guide › c › dam › en › us › td › docs ›...