Access Control in IdAS

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

This page describes work on adding access control policy management and enforcement to IdAS as part of Higgins 1.1

General Problem

IdAS provides APIs to access identity attributes, but currently ignores authorization in terms of defining an access control model, defining management APIs, and suggesting where in the architecture this type of policy should be enforced.

Some IdAS Context Providers provide access to backing data stores which themselves incorporate some kind of authorization model, but these vary widely in capabilities and model.

For various use cases (see below), we need a (one or more) definitions of an access control model, APIs that allow management (change permissions), and query (is userX allowed to perform operationY on resourceZ?), and an architecture that describes where authorization takes place.

Use Cases

• Access Control Use Cases

Terminology

subject

the requesting IdAS consumer. The UDI of an Agent Entity.

resource

the set of one or more Attributes and their associated value(s) of an Entity

Design Constraints

1. Model access control policy directly in Higgins Context Data Model
2. Keep Policy-related Entities cleanly segregated within the Context from "regular" data Entities
3. Enable the policy semantics to be serialized to/from XACML

Requirements

We are still gathering requirements by analysis of the use cases from above. The following is still a partial list of the requirements.

Policy Query

We need a query API to allow a subject (IdAS consumer) to ask if [for them] a given operation is allowed on a given resource

Policy Expression: Resource Scope

We need to be able to control access to all attributes held by an Entity or a set of Entities:

• We need to be able to control access to the value(s) of any attribute instance of a specified Entity instance
• We need to be able to control access to the value(s) of any attribute instance of an implied Entity; an Entity is an implied Entity if, starting at the Entity and by traversing higgins:partOf links, a specified Entity is reached

We need to be able to control access to specific attribute type/instance:

• Value(s) of all instances of a specified attribute type on every Entity in a specified Context
• Value(s) of all instances of a specified attribute type on every Entity of a specified Entity class
• Value(s) of a specified attribute instance on a specified Entity

Policy Expression: Subject Scope

The subject Entity of the access control policy must be specified:

• Explicitly: by its EntityId
• Implicitly: an Entity is an implied subject if, starting at the subject and by traversing higgins:memberOf links, a specified Group or Organization Entity is reached

Policy Expression: Operation Scope

We need a way for a Context to express what operations (e.g. read, modify, delete, etc.) are permitted on attribute values

Misc

We need to be able to conveniently express semantics such as "<subject(s)> are permitted read access on all attributes of entity except the password attribute"

• At present we believe this can be accomodated by requiring
  1. operators at different levels of resource "scope" to be combined
  2. "negative" operators (e.g. "deny read" as opposed to the positive "[allow] read")

Non-Requirements

Fodder for discussion. Nothing cast in stone:

1. We don't need a way to author a Context's policy --that's left to the Context implementation itself
2. We don't need a separate policy enforcement CP that can enforce policy on behalf of a CP plugged "underneath" it

Design Questions

Where is the Policy Enforcement Point (PEP)?

1. In each CP? Yes.
2. In a Service Endpoint above IdAS? No.
3. In a special CP that can be layered over CPs that don't support access control? Maybe later.

Policy Querying: Current Proposal

The Higgins team has agreed that the very first baby step to take in the access control space would be to allow an IdAS client to query whether an operation was permitted on some resource.

• IdAS getPermissions -- a simple, proposed IdAS API extension
• Directly interrogate policy objects and attributes (See Current Proposal)

Policy Expression: Current Proposal

The proposal is to use IdAS Entities to represent access control policy and to have relationship attributes on these Policy entities that capture the semantics of the policy.

New Classes

We will define a class called "Policy". We will further subclass Policy with an "AccessControlPolicy" subclass.

New Attributes

The following new attributes are proposed. Note: there are no cardinality restrictions on the use of attributes. One AccessControlPolicyEntity may have multiple higgins:accessControl attributes (of the kinds shown below).

• higgins:accessControl - supertype of all access control attributes
  • Used by AccessControlPolicyEntities
• higgins:operation
  • Subtype of higgins:accessControl
  • Value of this attribute is either RelativeEntityUDI string or AbsoluteAttributeUDI string
  • Concrete subtypes indicate the type of operation alllowed. Value is the resource (Entity or Attribute) being protected.
• higgins:add
  • Subtype of higgins:operation
  • Value is controlled resource. New resource instances may be added by the subject(s). If the resource in question is an Entity, then new instances of the same class of Entity may be added. If the resource in question is an Attribute then additional values of the attribute may be added.
• higgins:delete
  • Subtype of higgins:operation
  • Value is controlled resource. Resource may be deleted by the subject(s). If the resource in question is an Entity, the Entity may be deleted. If the resource in question is an Attribute then one or more values may be deleted (including deletion of all values, and thus the Attribute itself).
• higgins:modify
  • Subtype of higgins:operation
  • Value is controlled resource. Resource may be modified by the subject(s). If the resource in question is an Entity, then any or all of the Attributes of the Entity may be modified, added to, or deleted. If the resource in question is an Attribute, then any existing attribute values may be modified.
• higgins:read
  • Subtype of higgins:operation
  • Value is controlled resource. Resource may be read by the subject(s). If the resource in question is an Entity then the entire Entity may be read. If the resource in question is an Attribute, then the Attribute and each of its values may be read.
• higgins:subject
  • Subtype of higgins:accessControl
  • Value is the Agent (a kind of Entity) desiring access to some resource.

Further, some 'back-link' type attributes will be proposed that may be accessed from entities which are themselves subjects. For example, one attribute could list all the access control policy objects that an entity is listed on. Another attribute could be defined which is placed on a resource, and be used to list the subjects that are allowed to perform operations on that resource. These types of attributes would likely be auto-generated my the CP.

Resources

XACML Links

• A Brief Introduction to XACML --xml.coverpages.org from 2003
• Another introduction --from 2004
• Introductory PPT By Anne Anderson Feb 2007
• More detailed PPT by Lockhart(co-chair)

Implementations:

• http://sunxacml.sourceforge.net/ --Sun's XACML impl
• http://sunxacml.sourceforge.net/guide.html

Notes

• AuthZ can be done in different places (Paul has a picture):
  • In the backing data store
  • In each CP
  • In an "authZ" chaining CP
  • In front of IdAS
• We need to address the problem of referential integrity.
  • If AuthZ allows us to express something like "SubjectX has OperationY access to ResourceZ", then we must disallow renames of entities. Otherwise, if the "SubjectX" or "ResourceZ" entities are renamed, we have a problem where the AuthZ is disconnected.
    • Worse, if "SubjectX" is removed, and another one (with the same identifier) added, they will be unwittingly granted access.
  • One way of addressing this is to use durable names when pointing at subjects and resources.
• (from Phil Hunt)
  • Here is the link that I mentioned today... (this contains use cases from IGF that we can look at)
  • FWIW this is exactly what AAPML(a profile of XACMl) is intended to do. The problem we had with XACML was that you need the contextual information to drive it. This is in part what is driving the igf policy and transaction metadata policy assertions. Referenced here
  • Note: the items in the schema above are just my personal drafts of the "things" that need to be exchanged so that XACML can have the data it needs to make "good" policy decisions. I'm betting you'll come up with more.
  • I also think it shouldn't be too tough for Sun, Oracle, Novell, etc to update their directories to directly support XACML at some point. Since most directories have "plugin" capability, you could always write a plug-in that parses information (e.g. LDAP controls) and communicates with a XACML policy engine. In the mean-time, the case for IDAS as part of a proxy service is quite a powerful and interesting one.
• Access Control Teleconf 20080509
• Access Control Teleconf 20080520

See Also

• HOWL Update 1.1.103
• HOWL Update 1.1.104