OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Rule References


On Fri, 6 Jun 2003, bill parducci wrote:

> Polar Humenn wrote:
> 
> > Once rules incorporated referenced from outside the policy, it becomes 
> > unwieldy, as you cannot specify the evaluation semantics of a policy in 
> > the face of dynamically updating outside rules.
> 
> it's not 'outside of the policy' so much as 'outside of the system' that 
> i think causes the problems. this is a very appealing administrative 
> feature; assume that you have rule that is used in a large number of 
> policies:
> 
> grant access X if Y
> 
> where Y is some common condition like business hours. referential rules 
> will allow you to change a single rule for numerous policies in one 
> place. from a physical standpoint this greatly reduces the chance for 
> typographical error and ensures consistency across all policies 
> 'subscribed' to the rule.

Yes, but that is the point. A rule is not currently a point of
administration. We have all this *stuff* built around the Policy/Set
structure, such as signatures for integrity and such.

You can easily do what is required by this Rule Reference approach with a
PolicySet and a Policy and hold to the model that the policy is a mimimum
point of administration.

> semantic definition is still possible, but it is limited to a 'closed 
> system' (where updates to rules--or components of rules--stimulate the 
> system to reevaluate affected polices). not sure if this [closed system] 
> is a practical limitation, and it is unenforceable (particularly if 
> defined as an URI).

None of this operational stuff is specified in XACML. (It is in the CORBA
specification, however, as CORBA pays attention to such stuff).

> i find the overall concept attractive from an administration and policy 
> storage perspective, but only as an implementation specific optimization 
> mechanism. personally, i do it now for policy storage by *internally* 
> indexing virtually all policy components; none of it is apparent to the 
> XACML interface (not that it could handle it).

That is okay, once you've compilied the policy into its parts. However, 
if you change a component on the fly, that's a bad thing if you don't do 
it in a semantic preserving manor.

> what i think we need to consider is what XACML is defined to achieve. if 
> it is simply a mechanism for the *interchage* of policy information then 
> the integrity of the policy demands that all externally referenced 
> information be fully disclosed at the time of transfer (excluding 
> *static* references like specifications, standards, etc.) this then 
> means that an additional mechanism for the full disclosure of external 
> references must be defined or that the the contents of these references 
> be incorporated into the policy in expanded form.

Correct.

> neither is particularly appealing, so i would tend to agree that rule 
> references are NOT practical in the scope of the XACML standard as i 
> understand it. (the logic of which cascades down to conditions and 
> obligations as well).

I concur. Thanks. :)




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]