Difference between revisions of "Access Control in IdAS"

Revision as of 00:41, 25 February 2008

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

Fodder for discussion. Nothing cast in stone:

1. We need a way for a Context to express what can be done with its attributes--what's allowed.
2. We need to be able to control access to the following resources:
   1. Value(s) of all attribute instances irrespective of Context. [--Paul.socialphysics.org 15:40, 24 February 2008 (EST)not sure we need this level]
   2. Value(s) of all instances of a given attribute in a given Context
   3. Value(s) of all instances of an attribute on any Node represented by the "requesting" Entity [called a "subject' in XACML]
   4. Value(s) of an attribute on a specified Node

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 Options

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

How are the semantics of the policy expressed and accessed?

1. Define a Access Control type/syntax in IdAS, expose to IdAS consumers. See Simple Access Control Proposal.

Resources

XACML Links

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

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