Difference between revisions of "Access Control in IdAS"

Revision as of 02:42, 8 April 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

• Use a key to uniquely lookup a user in the backing store as a sufficiently privileged user and then use the authorization characteristics of that user for all subsequent requests.
• Access Control Use Cases

Requirements

Requirements to support R-Cards

1. We need a way for a Context to express what what operations are permitted the values of its attributes
   • 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 resolveable

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

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

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.

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
• If AuthZ allows us to express something like "UserX has OperationY access to ResourceZ", then we must disallow renames of entities.
  • Otherwise, if the "UserX" or "ResourceZ" entities are renamed, we have a problem where the AuthZ is disconnected.
    • Worse, if UserX is removed, and another one added, they will be unwittingly granted access.