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"

(Query for Permissions)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{#eclipseproject:technology.higgins}}
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins logo 76Wx100H.jpg|right]]  
[[Image:Higgins_logo_76Wx100H.jpg|right]]
+
  
This page describes work on adding access control policy management and enforcement to IdAS as part of Higgins 1.1
+
This page describes work on adding access control policy management and enforcement to IdAS as part of Higgins 1.1  
  
== General Problem ==
+
== 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.
+
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.  
  
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.
+
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.  
  
== Use Cases ==
+
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.
* [[Access Control Use Cases]]
+
  
== Requirements ==
+
== Use Cases  ==
  
=== Requirements to support R-Cards ===
+
*[[Access Control Use Cases]]
# 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
+
# We need to be able to control access to the following resources:
+
## Value(s) of all instances of a given attribute in a given Context
+
## Value(s) of all instances of an attribute on any Entity represented by the "requesting" IdAS consumer [called a "subject" in XACML]
+
## Value(s) of an attribute on a specified Entity [<--would be nice, not strictly needed for R-Cards]
+
# 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.
+
== Terminology  ==
* 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 ==
+
;subject
Fodder for discussion. Nothing cast in stone:
+
:the requesting IdAS consumer. The UDI of an Agent [[Entity]].
# We don't need a way to author a Context's policy --that's left to the Context implementation itself
+
;resource
# We don't need a separate policy enforcement CP that can enforce policy on behalf of a CP plugged "underneath" it
+
:the set of one or more [[Attribute]]s and their associated value(s) of an [[Entity]]
  
== Design Questions ==
+
== Design Constraints  ==
Where is the Policy Enforcement Point (PEP)?
+
 
# In each CP? Yes.
+
#Model access control policy directly in Higgins Context Data Model
# In a Service Endpoint above IdAS? No.
+
#Keep Policy-related Entities cleanly segregated within the Context from "regular" data Entities
# In a special CP that can be layered over CPs that don't support access control? Maybe later.
+
#Enable the policy semantics to be serialized to/from XACML
 +
 
 +
== Requirements  ==
 +
 
 +
We are still gathering requirements by analysis of the use cases from above. The following is still a partial list of the requirements.
 +
 
 +
=== Policy Query  ===
 +
 
 +
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
 +
 
 +
=== Policy Expression: Resource Scope  ===
 +
 
 +
We need to be able to control access to all attributes held by an Entity or a set of Entities:
 +
 
 +
*We need to be able to control access to the value(s) of any attribute instance of a specified Entity instance
 +
*We need to be able to control access to the value(s) of any attribute instance of an implied Entity; an Entity is an implied Entity if, starting at the Entity and by traversing higgins:partOf links, a specified Entity is reached
 +
 
 +
We need to be able to control access to specific attribute type/instance:
 +
 
 +
*Value(s) of all instances of a specified attribute type on every Entity in a specified Context
 +
*Value(s) of all instances of a specified attribute type on every Entity of a specified Entity class
 +
*Value(s) of a specified attribute instance on a specified Entity
 +
 
 +
=== Policy Expression: Subject Scope  ===
 +
 
 +
The subject Entity of the access control policy must be specified:
 +
 
 +
*Explicitly: by its EntityId
 +
*Implicitly: an Entity is an implied subject if, starting at the subject and by traversing higgins:memberOf links, a specified Group or Organization Entity is reached
 +
 
 +
=== Policy Expression: Operation Scope  ===
 +
 
 +
We need a way for a Context to express what operations (e.g. read, modify, delete, etc.) are permitted on attribute values
 +
 
 +
=== Misc  ===
 +
 
 +
We need to be able to conveniently express semantics such as "&lt;subject(s)&gt; 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  ==
 +
 
 +
Fodder for discussion. Nothing cast in stone:
 +
 
 +
#We don't need a way to author a Context's policy --that's left to the Context implementation itself
 +
#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)?  
 +
 
 +
#In each CP? Yes.  
 +
#In a Service Endpoint above IdAS? No.  
 +
#In a special CP that can be layered over CPs that don't support access control? Maybe later.
 +
 
 +
== Policy Querying: Current Proposal  ==
  
== 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.  
 
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 [[Access_Control_in_IdAS#Current_Proposal|Current Proposal]])
 
  
== Policy Expression: Current Proposal ==
+
*[[IdAS getPermissions]] -- a simple, proposed IdAS API extension
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.
+
*Directly interrogate policy objects and attributes (See [[Access Control in IdAS#Current_Proposal|Current Proposal]])
 +
 
 +
== 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 a class 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  ===
  
===New Classes===
+
*[http://xml.coverpages.org/XACML-Guide200303.html A Brief Introduction to XACML] --xml.coverpages.org from 2003
We will define an [[Entity]] subclass called "Policy". We will further subclass Policy with an "AccessControlPolicy" subclass.
+
*[http://dev2dev.bea.com/pub/a/2004/02/xacml.html Another introduction] --from 2004
 +
*[http://colab.cim3.net/file/work/Expedition_Workshop/2007-02-27_IdentityManagementExploration/AnneAnderson_XACML_20070215.pdf Introductory PPT By Anne Anderson] Feb 2007
 +
*[http://xml.coverpages.org/Lockhart-NAC-XACML-Update2007.pdf More detailed PPT by Lockhart(co-chair)]
  
===New Attributes===
+
Implementations:
  
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).
+
*http://sunxacml.sourceforge.net/ --Sun's XACML impl
* higgins:accessControl - supertype of all access control attributes
+
*http://sunxacml.sourceforge.net/guide.html
** 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.
+
== Notes ==
  
== Resources ==
+
*AuthZ can be done in different places (Paul has a picture):
=== XACML Links ===
+
**In the backing data store
* [http://xml.coverpages.org/XACML-Guide200303.html A Brief Introduction to XACML] --xml.coverpages.org from 2003
+
**In each CP
* [http://dev2dev.bea.com/pub/a/2004/02/xacml.html Another introduction] --from 2004
+
**In an "authZ" chaining CP
* [http://colab.cim3.net/file/work/Expedition_Workshop/2007-02-27_IdentityManagementExploration/AnneAnderson_XACML_20070215.pdf Introductory PPT By Anne Anderson] Feb 2007
+
**In front of IdAS
* [http://xml.coverpages.org/Lockhart-NAC-XACML-Update2007.pdf More detailed PPT by Lockhart(co-chair)]
+
*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)
 +
**[http://www.projectliberty.org/index.php/liberty/content/download/3432/22922/file/Liberty_Id_Governance_mrd-v1.0.pdf 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 [http://idgov.svn.sourceforge.net/viewvc/idgov/IGF_AttrSvcs/trunk/org.openliberty.igf.attributeServices/schemas/ 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]]
  
Implementations:
+
== See Also  ==
* http://sunxacml.sourceforge.net/ --Sun's XACML impl
+
* http://sunxacml.sourceforge.net/guide.html
+
  
== Notes ==
+
*[[HOWL Update 1.1.103]]  
* AuthZ can be done in different places (Paul has a picture):
+
*[[HOWL Update 1.1.104]]
** 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)
+
** [http://www.projectliberty.org/index.php/liberty/content/download/3432/22922/file/Liberty_Id_Governance_mrd-v1.0.pdf 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 [http://idgov.svn.sourceforge.net/viewvc/idgov/IGF_AttrSvcs/trunk/org.openliberty.igf.attributeServices/schemas/ 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 ==
+
[[Category:Higgins_IdAS]]
* [[Backlog]]
+
** [[IdAS Backlog]]
+
[[Category:Higgins IdAS]]
+

Latest revision as of 15:11, 18 July 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
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
the set of one or more Attributes and their associated value(s) 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 Entities
  3. Enable the policy semantics to be serialized to/from XACML

Requirements

We are still gathering requirements by analysis of the use cases from above. The following is still a partial list of the requirements.

Policy Query

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

Policy Expression: Resource Scope

We need to be able to control access to all attributes held by an Entity or a set of Entities:

  • We need to be able to control access to the value(s) of any attribute instance of a specified Entity instance
  • We need to be able to control access to the value(s) of any attribute instance of an implied Entity; an Entity is an implied Entity if, starting at the Entity and by traversing higgins:partOf links, a specified Entity is reached

We need to be able to control access to specific attribute type/instance:

  • Value(s) of all instances of a specified attribute type on every Entity in a specified Context
  • Value(s) of all instances of a specified attribute type on every Entity of a specified Entity class
  • Value(s) of a specified attribute instance on a specified Entity

Policy Expression: Subject Scope

The subject Entity of the access control policy must be specified:

  • Explicitly: by its EntityId
  • Implicitly: an Entity is an implied subject if, starting at the subject and by traversing higgins:memberOf links, a specified Group or Organization Entity is reached

Policy Expression: Operation Scope

We need a way for a Context to express what operations (e.g. read, modify, delete, etc.) are permitted on attribute values

Misc

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 a class 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