xacml message

Subject: Re: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)

From: rich levinson <rich.levinson@oracle.com>
To: Hal Lockhart <hal.lockhart@oracle.com>
Date: Thu, 29 Nov 2012 15:42:45 -0500

+1 to Hal's comment.

Have 2 kinds of Policy elements introduces what, imo, is an unnecessary
level of complexity. Given the fact that we have "Category" to distinguish
the types of "Xacml entity" (we really need a term for this, that is more
useful than just calling a collection of attributes a "category", I am implicitly
suggesting "entity" because that's what it is - a collection of attributes
describing some entity in the organization environment, which could be
a user, a special kind of user, a resource, a special kind of resource, etc.).

i.e. given the fact that we have "Category" to distinguish the types of
"Xacml entity", it would seem to me that anything having to do with
so-called administrative policies could have their Xacml entities in
a special category or categories reserved for administrative things.
Then the Target can easily be used to split things off right below
the root PolicySet to handle administration in one branch of the
tree and all other things in another branch.

To me this approach is nearly infinitely more desirable than creating
new elements to distinguish "types" of policies.

  Thanks,
  Rich


On 11/29/2012 2:57 PM, Hal Lockhart wrote:

I am sure I don't understand all the subtleties of this debate, but it seems to me that for the organization maintaining a large policy hierarchy it will be easier to have a single tree with both admin and access policies than two trees (or the equivalent).

The reason is that the policy set hierarchy is used to partition the various scopes of concern within the organizations. It seems to me that the constructs used to partition the space for the purposes of applicable policy will usually be the same as those used to partition the space for scope of administrative responsibility. With two trees, its seems to me that often it will be necessary to make synchronized parallel changes to both trees, which is a good thing to avoid if possible.

For example, suppose parts of the policy tree pertain to different subsidiaries within a corporation. It is likely that administrative responsibilities will also be divided by subsidiary. If we need to change a Target which selects server from some subsidiary, it is likely the same change will be required in the admin tree as well.

Hal

-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Thursday, November 29, 2012 7:33 AM
To: Steven Legg
Cc: xacml@lists.oasis-open.org
Subject: [xacml] Re: Policy Labelling (was Re: Delegation and on-
permit-apply-second)

Hi Steven,

On 2012-11-28 06:28, Steven Legg wrote:

Hi Erik,

On 27/11/2012 8:43 PM, Erik Rissanen wrote:

Hi Steven,

See inline.

On 2012-11-05 05:42, Steven Legg wrote:

Hi Erik,

On 1/11/2012 6:40 PM, Erik Rissanen wrote:

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.

I agree completely.

So, I would agree with you to these changes.

Reflecting on what you say here and what you were saying during the
TC meeting makes me think you are assuming more than the minimal
change required to dispense with category prefixing, in which case
there are some technical choices to be discussed. I'll start by
describing the minimal change.

The reduction procedure, as currently described by the
administration profile, begins when the PDP encounters an
applicable, untrusted access policy. Let's call it 'A'. A reduction
graph is formed by considering each ordered pair of policies in the

policy set that contains 'A'.

Let's
call that policy set 'B'. To even get to the point of evaluating
access policy 'A', policy set 'B' must be an access policy set
(which is to say, it has a target that can only be satisfied by an

access request).

For policy 'A' to be authorized at all there must be at least one
sibling policy of 'A' that is an administrative policy. Let's call
it policy 'C'.
So an access policy set like 'B' must be allowed to have children
that are either access policies (like 'A') or administrative
policies (like 'C').
In the current scheme we distinguish between access policies and
administrative policies by whether or not they have attribute
designators referring to prefixed categories. In the new scheme we
would tell the difference by the element name of the policy, e.g.,
either<Policy>  or<AdministrativePolicy>, and in the process
exclude the unhelpful possibility of hybrid policies.

It is also possible for a sibling of policy 'B' to be an
administrative policy set, which is to say, a policy set with a
target that can only be satisfied by an administrative request. We
can likewise distinguish between access policy sets and
administrative policy sets by the element name, e.g., either
<PolicySet>  or<AdministrativePolicySet>. Let's say we have an
administrative policy set 'D' that is a sibling of policy 'A'. Both
policy 'C' and policy set 'D' are considered when reducing policy
'A'. In which case they are evaluated with respect to an
administrative request.
Policy
set 'D' is only ever considered when processing an administrative
request, so any access policy or access policy set children of
policy set 'D'
will
never be evaluated. We might as well disallow such children.

In summary, what we have for the minimal change is<PolicySet>
elements that may have<Policy>,<AdministrativePolicy>,

<PolicySet>

and<AdministrativePolicySet>  children, and
<AdministrativePolicySet>  elements that may have only
<AdministrativePolicy>  and<AdministrativePolicySet>  children.

The fact that an access policy set can have administrative child
policies and policy sets is a non-issue for most policy set
combining algorithms.
In the current scheme the administrative children would always
evaluate to NotApplicable when evaluating an access request. In the
new scheme the administrative children would be skipped (or
automatically
NotApplicable)
when evaluating an access request. Either way, the result of the
combining algorithm is unaffected. The one exception is the
on-permit-apply-second combining algorithm because it limits a
policy set to exactly two children.
If, for an access policy set, those children are both access
policies, then in practice they have to be trusted policies because
there is no room for any administrative policies to authorize
untrusted policies (note this is also the case with the current
administration profile). If either child of an access policy is an
administrative policy, then the policy set will never be

applicable.

To make the on-permit-apply-second combining rule more useful in an
administrative setting, the restriction to two children should be
relaxed to two access children and any number of administrative
children when the combining rule is used in an access policy set.
The "first" and "second" children should be taken to mean the first
and second access children, or we can insist that any

administrative

children must come after the two access children. What to do in the
case of an administrative policy set with the on-permit-apply-

second

combining rule is not so obvious. If we limit it to two
administrative children, then those children would have to be
trusted in practice. We could say that the first two children are
considered by the combining algorithm and any subsequent children
are only used if reduction of untrusted children is required.

I think the above "minimal change" seems good. I don't think it is a
big problem that the on-permit-apply-second is meaningful only in
context of trusted children, since it is intended to solve the issue
of a condition in policies, and for that purpose everything work
fine.

That covers the minimal change. The more substantial change is a
complete separation of access and administrative policies and

policy

sets.
That is,
a<PolicySet>  can only have<Policy>  and<PolicySet>  children, and
an<AdministrativePolicySet>  can only have<AdministrativePolicy>
and<AdministrativePolicySet>  children. An access request would
initially be assessed against the collection of access policies and
access policy sets.
The administrative policies and policy sets would become involved

if

there are any untrusted access policies or policy sets to be
reduced. A revision of the reduction procedure would be necessary
and I see two main possibilities.

I don't like the above since this introduces a top level construct

in

the PDP which is different from any of the regular XACML policy
constructs.

As opposed to the current scheme that introduces a mid-level

construct

(the reduction graph built from pair-wise assessment) which is
different from the regular XACML policy set evaluation ?

It is a fact that the initial request to the PDP is an access
request,
so the access request must match the "top level policy construct" in
the PDP.

It still would.

Also, if the administrative
profile is going to be of any use, this top level policy construct
also has to also be able to contain administrative policies.

Only if you assume that everything has to be wrapped up in a single,
physical policy set.

It would, in a broad sense. It does not have to be a policy set
strictly. Naturally, in your proposal it would be something different.
It would be nice if we would not need this "different thing".

An important aspect of the policy labelling solution is that
administrative policies and policy sets are automatically
NotApplicable when evaluating access requests, and access policies

and

policy sets are automatically NotApplicable when evaluating
administrative requests. Section 7.17 of the core specification has
this to say about request evaluation:

     "the PDP is defined by a policy-combining algorithm and a set of
policies
      and/or policy sets. The PDP SHALL return a response context as

if

it had
      evaluated a single policy set consisting of this policy-

combining

algorithm
      and the set of policies and/or policy sets".

We could assume that this virtual, single policy set is exempt from
the separation of access policy and administrative policy. The
children could be access policies and/or access policy sets and/or
administrative policies and/or administrative policy sets. Some of
these children will be automatically NotApplicable depending on
whether it is an access request or an administrative request that is
being evaluated.

Alternatively, we could (with respect to option 2) assume that 7.17
applies to access request evaluation and write similar text to cover
administrative request evaluation. That is, the PDP is defined by a
policy-combining algorithm and a set of access policies and/or access
policy sets, and a policy-combining algorithm (maybe the same one)

and

a set of administrative policies and/or administrative policy sets.

Thus the top level policy construct is something different from the

above policy

constructs which you listed.

That adds more specification and implementation cost, compared with

PDP which simply starts with a selected top level policy set, which
is semantically no different than any other policy set in XACML.

In the context of option (2), and given that an implementation

chooses

to restrict the "set of policies and/or policy sets" in 7.17 to
exactly one policy set, is it really that difficult to have a

selected

top level access policy set as the place for the PDP to start for an
access request and also a selected top level administrative policy

set

as the place for the PDP to start for an administrative request ?

No, it's not difficult, but it means that delegation will only work at
the top level. A sub policyset cannot use delegation within itself in
that case, which is a restriction for a collaborative policy authoring.

The first possibility is that we keep the idea of a reduction

graph,

only
instead of the nodes in the graph being the siblings of the
untrusted access
policy being reduced, the nodes are the standalone administrative
policies
and policy sets. In effect, every access policy has every

standalone

administrative policy or policy set as an implied sibling when
forming the
reduction graph. We have the choice when reducing an untrusted
administrative
policy whether to consider the actual siblings of that
administrative policy
when forming the reduction graph (call this (1.a)), or to form the
graph
from the standalone administrative policies and policy sets (call
this (1.b)),
just as we would for untrusted access policies.

The second possibility (call this (2)) is to do away with the

reduction

graph and simply assess an administrative request against the
collection
of administrative policies and policy sets just as we assess an

access

request against the collection of access policies and policy sets.
If we
find an untrusted policy (in either collection), then we form the
necessary administrative request and assess it against the
collection of
administrative policies and policy sets.

An effect of options (1.b) and (2) is that in the process of
reducing an
administrative policy we may encounter that very same

administrative

policy.
If we do, then we treat it as NotApplicable rather than recursively
reducing
it. To do otherwise would open the possibility of self-authorizing,
untrusted
policies. Note that this effect doesn't arise with the delegation

graph

because policies aren't paired with themselves.

Also with options (1.b) and (2) we don't need to do anything about

the

on-permit-apply-second combining rule. Administrative policies no
longer
need to be siblings of the untrusted policies they authorize, so

the

on-permit-apply-second combining rule can still insist on having
exactly
two children.

I would very much like us to choose option (2) because working out
where
to put an administrative policy under the current scheme is a

burden

policy
writers can do without. Take the simple case where User A delegates

all

rights to User D. This is a very simple administrative policy that
basically
says "if the delegate is User D, then Permit". The issue is where

to

put it.
User A needs to place it (by copy or by reference) in every policy
set where
User D will potentially be creating access policies. Furthermore,

as

new
policy sets are created that User D might put policies into, User A
will have
to put the administrative policy in there as well. Conversely, if
User A
isn't thorough or proactive in placing the administrative policy,
then User D
will be limited in the rights he or she can actually exercise.
Compounding
the difficulties is the fact that in the general case, because of
multi-valued attributes and augmentation of the delegate category

by

a context handler, practially any untrusted policy can be

authorized

by any
administrative policy. It all depends on the request context. It is
only
by making assumptions about certain attributes being single-valued
or by
knowing about correlations between the attributes of an access
subject that
we can begin to predict which untrusted policies will be authorized

by

which administrative policies in the absence of any specific

request

context.
These are things that users shouldn't have to be concerned with

when

creating
administrative policies. Options (1.b) and (2) mean that they don't
have to
be. Option (2) is the conceptually simpler of the two, and can
simulate (1.b)
if desired.

I don't agree that option 2 is simpler conceptually. I would say

it's

the opposite since it introduces
another type of policy combining at the top level.

Option (1.b) calls for forming a reduction graph from the top level
administrative
policies and/or policy sets, which is quite different from what 7.17
requires
for access requests. Option (2) is just like 7.17, except the

policies or

policy sets will be different ones.

Also, being able to mix in admin policies in nested access policies
is useful for creating hierarchical
structures, where a delegated policy contains nested delegation
itself. This sort of recursion is useful for
being able to import a full policy set of a sub-organization which
internally might want to use delegation.

I'm sceptical about the utility of that. Importing policy from a
sub-organization
isn't necessarily going to be easy. For example, a user of the
sub-organization
may have "read" access to everything, which is alright in the scope

of

the
sub-organization, but may not be appropriate in the scope of the

parent

organization. Access rights will generally need to be reconsidered,

which

will involve rewriting and reorganizing policy for both the parent
organization
and the sub-organization, and the administrative policies won't be
immune to that.
Even if restricting the scope of the sub-organization's

administrative

policies
to the sub-organization's access policies is useful, importing the
policy of
a sub-organization is a relatively infrequent event. Option (2) is
about making
delegation easier to use all the time. Keeping the reduction graph so
that
importing a policy set from a sub-organization is (maybe) easier is
making the
wrong trade off.

I think collaborative policy authoring, whereby anything can be nested,
is valuable.

Also, with option (2) the parent organization would be importing an
access policy
set and a separate administrative policy set. If there is a simple

way

to distinguish
the issuers in the sub-organization from issuers in the parent
organization (e.g.,
by the domain name in their email addresses), then this could be

added

to the
target of the administrative policy set, effectively restricting the
scope of the
sub-organization's administrative policies to the sub-organization's
access
policies, even though they are separated.

But it would put everything at the top level. I would think that
recursion and nesting would be useful to handle very large policy sets.

Regards,
Steven

Best regards,
Erik

Regards,
Steven

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

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

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


---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org

References:
- Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
  - From: Erik Rissanen <erik@axiomatics.com>
- Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
  - From: Steven Legg <steven.legg@viewds.com>
- Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
  - From: Erik Rissanen <erik@axiomatics.com>
- Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
  - From: Steven Legg <steven.legg@viewds.com>
- Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
  - From: Erik Rissanen <erik@axiomatics.com>
- RE: [xacml] Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
  - From: Hal Lockhart <hal.lockhart@oracle.com>