Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

[Erik Rissanen <erik@axiomatics.com>]

Hi Steven,

I do think there is some practical value in being able to collect any 
types of policies into a single policy set, but I agree that the value 
probably is not that big. In come cases where someone would hand over a 
policy set "here are all my access and admin policies", they would have 
to hand over two separate sets of policies instead.

And, yes, when I think about it more, the evaluation logic change is 
small. And there is actually one additional benefit. The explicit 
marking of a policy as an admin policy is probably simpler conceptually 
to users than to use weird attribute category names.

So, I would agree with you to these changes.

Best regards,
Erik


On 2012-11-01 06:14, Steven Legg wrote:
> Hi Erik,
>
> On 31/10/2012 11:35 PM, Erik Rissanen wrote:
> > Hi Steven,
> >
> > Sorry about the slow response to this.
> >
> > As I see it, there are two benefits to the category prefixing:
> >
> > 1. A policy can be mixed admin/access.
>
> How is that a particular benefit when any such mixed policy (or policy 
> set) can be
> rewritten as a pair of a pure access policy and a pure administrative 
> policy, together
> having exactly the same effect ? A policy that authorizes itself is 
> pointless, and
> merging an access policy with an administrative policy that authorizes 
> unrelated
> access policies is weird and confusing, so why do it ?
>
> > 2. We don't need to change the XACML evaluation logic as much. To 
> > implement the delegation model, the PDP
> > can use the normal XACML evaluation on admin requests, while building 
> > the delegation graph.
> >
> > I think the second is a significant benefit. It would significantly 
> > complicate both the administrative spec
> > and the implementation if we need to define additional modes of XACML 
> > policy evaluation.
>
> The delegation model is already a significant departure from normal 
> XACML evaluation,
> what with building the delegation graph and forming administrative 
> requests. Those
> things would still be there. The complexity trade off is between 
> category prefixing
> (which is not yet complete because it has unresolved issues) and a 
> simple boolean
> test during request processing to see if the kind of the policy 
> matches the kind
> of the request (i.e., access versus administrative). That test is 
> simple and efficient
> compared to category prefixing.
>
> > What about changing the prefix so it works with all cases?
>
> The only thing that comes to mind that would be syntactically valid is a
> prefix to the scheme name. For example, http://example.com/foobar becomes
> delegated-http://example.com/foobar.
>
> > Or changing the admin category to something else
> > than it being based on a prefix?
>
> That's difficult without making changes to the core syntax.
>
> > By means of some other kind of algorithm, or maybe an explicit table?
>
> Labelling the policies would be much easier than a managing a mapping 
> table.
>
> Regards,
> Steven
>
> > Best regards,
> > Erik
> >
> >
> > On 2012-09-03 07:03, Steven Legg wrote:
> > > Hi Erik,
> > >
> > > On 1/09/2012 1:23 AM, Erik Rissanen wrote:
> > > > I don't think we change the delegation model in this way since it 
> > > > would mean changing the core schema, which
> > > > we really don't want to do at this stage.
> > >
> > > I originally suggested an XML attribute for the label, which would need
> > > a change to the core schema, but there is another way to label the
> > > policies without changing the core schema and that is substitution
> > > groups for Policy and PolicySet. For example:
> > >
> > >     <xs:element name="AdministrativePolicy" type="xacml:PolicyType"
> > >                 substitutionGroup="xacml:Policy"/>
> > >
> > >     <xs:element name="AdministrativePolicySet" 
> > > type="xacml:PolicySetType"
> > >                 substitutionGroup="xacml:PolicySet"/>
> > >
> > > In a way this is better than a simple XML attribute because it is more
> > > visually distinctive. It would be desirable for AdministrativePolicy
> > > and AdministrativePolicySet to be in the same namespace as Policy
> > > and PolicySet, but if they have to be in their own namespace so be it.
> > >
> > > > Also, I think we did consider labeling policies like this in early
> > > > stages of the delegation work. I don't remember right now why we 
> > > > did not go that way, but I suspect there
> > > > was a reason.
> > >
> > > I've found and reported on a bunch of problems with category prefixing,
> > > so there are reasons to reconsider using labelling. If the purpose of
> > > the prefixing is just to ensure that administrative policies aren't
> > > applicable when evaluating access requests, and vice versa, then
> > > labelling is a simpler and cleaner way to achieve the same end.
> > >
> > > > Probably that the current mechanism is more flexible.
> > >
> > > It's more flexible in that it allows hybrid policies that are a bit
> > > access policy and a bit administrative policy. I can't think of a
> > > good reason to want to do that, and in any case, it is always possible
> > > to split a hybrid policy into a pure access policy and a pure
> > > administrative policy. I would happily forego this dubious flexibility
> > > to get rid of category prefixing and its problems.
> > >
> > > Regards,
> > > Steven