Next in thread → Next in month →

RE: [xacml] How to implement hierarchies in our model

From
System <>
Date
2001-11-28T18:37:00+00:00
ID
Thread
RE: [xacml] How to implement hierarchies in our model
MHonArc v2.5.2 -->

xacml message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]

Subject: RE: [xacml] How to implement hierarchies in our model

From: Hal Lockhart <>

To: 'Tim Moses' <>, 'XACML' <>

Date: Wed, 28 Nov 2001 18:34:26 -0500

Title: How to implement hierarchies in our model

The 
general problem being discussed is that many existing accesss control systems 
imbue certain attributes with special semantics. In contrast, X.509 and SAML, 
for example, consider that attributes are just name value pairs and special 
semantics are up to the implementation. Examples of special semantics include: 
clearances, nested roles and dynamic roles. I feel compelled to point 
out, in passing, that the the hierachy represented by clearances and the 
hierarchy represented by nested roles (groups) are completely different from 
each other.

 

Tim's message represents one of the three choices I suggested 
for dealing with special attribute semantics.

 

1. 
Express the semantics explicitly using the XACML policy model language. 

 

Tim 
has shown that this can be done and also that it is likely to lead to 
complicated looking policies that would likely be repeated over and over again. 
Possibly this could be addressed with some kind of Macro facility. The major 
advantage is that there is just one policy language (contrast 3 
below)

 

2. 
Pick some important cases and define the semantics in English as a "built-in" 
feature of the language. 

 

This 
would provide a cleaner language and probably more efficient processing. However 
we would haave to arbitrarily pick some cases and reject others, which no doubt 
some people would object to. There would be no way for others to add what we had 
left out or create minor variations, except as in 1 above.

 

3. 
Define a way of specifying these special semantics. 

 

This 
would allow others to extend XACML as they see fit. Presumably we would pick 
some important cases as in 2 and specify them. There would be two policy 
languages, but most people would not use the second one or need to understand 
it. The main concern in my mind is I have very little idea what this would look 
like.

 

There 
may of course be other approaches as well.

 

Hal
Next in thread → Next in month →