Access Control in IdAS

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.

Proposals

Where is the Policy Enforcement Point (PEP)?

1. Service Endpoint above IdAS
2. In a special CP
3. In each CP

How are the semantics of the policy expressed and accessed?

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

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.

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