[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Administration & Delegation - Was: Re: [xacml] Current state of profiles
Hi Hal, On 8/08/2014 3:38 AM, Hal Lockhart wrote:
I would like to see what we need to do to move forward on the Privacy and the Admin&Deleg Profiles. I will comment separately on the Privacy Profile. I cannot even find the Admin&Deleg thread. Does anyone have a reference? In both cases, my questions are: is there a concrete proposal? Are the changes needed now or is this just an enhancement request?
There are two main unresolved topics of discussion for the Administration and
Delegation Profile. The first is category prefixing. There are three problems
with category prefixing that are introduced in these three threads on the
XACML comment list.
A Problem with the "delegated:" Prefix
https://lists.oasis-open.org/archives/xacml-comment/201205/msg00000.html
XPathCategory During Reduction
https://lists.oasis-open.org/archives/xacml-comment/201205/msg00004.html
Multiple Decision Requests During Reduction
https://lists.oasis-open.org/archives/xacml-comment/201106/msg00003.html
The first of those threads canvassed some possible solutions, but by far my
preferred solution is to do away with category prefixing and use policy labelling
instead, which was introduced in a later thread.
Policy Labelling
https://lists.oasis-open.org/archives/xacml/201209/msg00001.html
Erik appeared to accept the idea of policy labelling:
https://lists.oasis-open.org/archives/xacml/201211/msg00000.html
The Policy Labelling thread then morphed into the second main topic of discussion,
which was about alternatives to using the reduction graph to evaluate administrative
requests.
https://lists.oasis-open.org/archives/xacml/201211/msg00016.html
My objection to the current mechanism is that it is too difficult to use in practice.
To quote from the aforementioned email:
... 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, practically 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.
The reduction graph also limits what one can do with administrative policies
compared to access policies and I was hoping to give writers of administrative
policies the same freedom as writers of access policies.
I was proposing doing away with the reduction graph and simply assessing 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.
It is potentially a recursive procedure because administration policies may also
need to be authorized by further administrative requests. In the worst case the cost
of the procedure is roughly N! (N factorial) compared to roughly N * N for the
reduction graph. The worst case is the rather dysfunctional situation where every
administrative policy authorizes every access policy and every other administrative
policy. The typical case would be nothing like that, but as I have no useful
empirical data on what "typical" actually is, there was an action item on me to find
an optimization with better worst case performance. I haven't found one.
Rather than make a choice between the impractical and the expensive, I will now propose
a compromise. The management difficulties of the current method would be alleviated
if the reduction graph were formed from the sibling administrative policies of the
access policy being reduced *and* the sibling administrative policies of each policy
set enclosing the access policy being reduced. In this way an administrative policy
with wide scope, such as "if the delegate is User D, then Permit", could be placed
once in an outer policy set where it will automatically affect all the nested
policy sets, rather than being laboriously reproduced in all of those nested policy
sets. Any new nested policy sets would be automatically covered by the administrative
policy without further action by the policy administrator. Administrative policies
would still have some limitations compared to access policies, but at least they
wouldn't be such a burden to maintain.
Since we're in the neighbourhood, this issue with the reduction graph could also be
addressed:
Reduction Should Use Extended Indeterminate Values
https://lists.oasis-open.org/archives/xacml-comment/201106/msg00004.html
Regards,
Steven
Let’s have some discussion on the call today. Hal *From:*Erik Rissanen [mailto:erik@axiomatics.com] *Sent:* Tuesday, July 29, 2014 4:47 AM *To:* xacml@lists.oasis-open.org *Subject:* [xacml] Current state of profiles All, I did a review of the current status of the profiles I am the editor of. * XACML 3.0 Additional Combining Algorithms Profile Version 1.0 I just posted WD-08 which corrects a typo which was found during the public review. The change is non-material so we should vote the profile up to CS without another public review. * XACML v3.0 Administration and Delegation Profile Version 1.0 There is an ongoing debate about the technical contents of this profile. * XACML v3.0 XML Digital Signature Profile Version 1.0 Latest document is CS-02. https://www.oasis-open.org/news/announcements/xacml-v3-0-xml-digital-signature-profile-version-1-0-committee-specification-02-p I guess the next step is to get three statements of use. * XACML v3.0 Privacy Policy Profile Version 1.0 Latest document is csprd-02. https://www.oasis-open.org/news/announcements/15-day-public-review-for-xacml-v3-0-privacy-policy-profile-v1-0-ends-june-6th However, there is an ongoing debate about the technical contents of this profile, so we cannot proceed until those discussions have been resolved. There were a couple of comments during the public review: https://lists.oasis-open.org/archives/xacml/201405/msg00041.html https://lists.oasis-open.org/archives/xacml/201406/msg00000.html * XACML v3.0 Hierarchical Resource Profile Version 1.0 Latest document is CS-02: https://www.oasis-open.org/news/announcements/xacml-v3-0-hierarchical-resource-profile-version-1-0-committee-specification-02-p I guess the next step is to get three statements of use. * XACML v3.0 Multiple Decision Profile Version 1.0 Latest document is CS-02: https://www.oasis-open.org/news/announcements/xacml-v3-0-multiple-decision-profile-version-1-0-published I guess the next step is to get three statements of use. * XACML SAML Profile Version 2.0 I recently posted WD-19 of this profile, which corrects typos. The changes are non-material so we should vote this profile to CS without another public review. * XACML v3.0 Core and Hierarchical Role Based Access Control (RBAC) Profile Version 1.0 Latest document is WD-11. The changes are non-material since only non-normative text was changed, but a lot of text was impacted, so I think we should do a CS draft public review as the next step. Best regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]