Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Access Control in IdAS"

(Requirements)
(Requirements)
Line 29: Line 29:
 
## Value(s) of all instances of an attribute on any Entity represented by the subject  
 
## Value(s) of all instances of an attribute on any Entity represented by the subject  
 
## Value(s) of an attribute on a specified Entity
 
## Value(s) of an attribute on a specified Entity
# We need to be able to control access based on subject identifiers
+
# We need to be able to control access based on who the requesting subject is (i.e. the subject's identifier)
 +
# 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
 +
#*# operators at different levels of resource "scope" to be combined
 +
#*# "negative" operators (e.g. "deny read" as opposed to the positive "[allow] read")
  
 
== Non-Requirements ==
 
== Non-Requirements ==

Revision as of 22:47, 7 July 2008

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

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

Terminology

subject
the requesting IdAS consumer. The UDI of an Agent Entity.
resource
a single Attribute of an Entity or the entire set of attributes 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 Entitites

Requirements

  1. We need a way for a Context to express what operations (e.g. read, modify, delete, etc.) are permitted on attribute values
  2. 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
  3. 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 subject
    3. Value(s) of an attribute on a specified Entity
  4. We need to be able to control access based on who the requesting subject is (i.e. the subject's identifier)
  5. 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.

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 an Entity subclass 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

Implementations:

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

Back to the top