xacml — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
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 <[email protected]>
- To: 'Tim Moses' <[email protected]>, 'XACML' <[email protected]>
- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] — [Date Index] | [Thread Index] | [Month Index] | [List Home]