Difference between revisions of "Access Control in IdAS"

Revision as of 02:45, 9 May 2008

{{#eclipseproject:technology.higgins}}

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

Requirements

Requirements to support R-Cards

1. We need a way for a Context to express what operations are permitted on attribute values
   • See IdAS getPermissions for a simple proposal where the operations are limited to get, add, modify, and delete
2. We need to be able to control access to the following resources:
   1. Value(s) of all instances of a given attribute in a given Context
   2. Value(s) of all instances of an attribute on any Entity represented by the "requesting" IdAS consumer [called a "subject" in XACML]
   3. Value(s) of an attribute on a specified Entity [<--would be nice, not strictly needed for R-Cards]
3. We need to be able to control access based on the OpenID/i-name/i-number of other Entities (e.g. the Bob, Charles and David mentioned in the example below) although these Entities may not be resolvable

Here is an example policy.

• We have a Person Entity representing "Alice" in a Context
• In this Context each Person Entity has a http://fabrikam.com/shoe-size attribute
• On all Person Entities, all values of the shoe-size attribute can be:
  • Modified by Alice
• On the Person Entity representing the user="Alice", the values of the shoe-size attribute can be:
  • Modified by Alice
  • Readable by Bob, Charles and David <-- Alice has shared this attribute with Bob, Charles and David

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. Service Endpoint above IdAS <-- ??
2. In a special CP <-- maybe later
3. In each CP <-- at least for now

Query for Permissions

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)

Current Proposal

We have a proposal to make use of IdAS Entities to manage Access Control and to have some relationships between these Entities and the subjects and resources they refer to in order to facilitate different kinds of queries.

So, a new "policy" entity type will be proposed, and from that an "access control policy" subtype will be proposed. These access control policy entities will have *at least* subject, resource, and operation attributes, and likely others that will help us as the use cases grow to include more sophisticated access control policy expressions.

Further, some 'backlink' 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.

See File:Policy-Entities.pdf for an overview of this proposal.

• Policy entity type
  • In case there's anything common among different kinds of policy classes of entities
• AccessControlPolicy entity type (subtype of Policy)
  • Attributes:
    • resource
      • Attribute type should allow one to refer to a:
        • Context,
        • Entity,
        • Attribute (on a specific Entity), (on a set of Entities), (on a context)
        • Attribute Value (same granularity as above)?
          • This would allow one to say something like: "Bob can update integers between 5 and 10 on Alice's Shoe Size attribute". Not sure if this is needed.
    • subject
      • Attribute type should be that of an Entity or a pointer to an Entity
      • Needs to have referential integrity properties
    • operation
      • Attribute type should allow us to define some base operations like read, modify, delete, and add, but should also allow others to be defined in the future.
        • URI seems like a good fit for the attribute type here.
    • others?

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.