[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Administration & Delegation - Was: Re: [xacml] Current state of profiles
I created new issues in the wiki (numbers 94-101) all dealing with the A & D Profile. Here is my take on where we stand on them. First I believe we essentially have consensus on these issues: 94. Admin Profile: Problem with "delegated:" prefix Prefixing doesn't work we need something different. I think Stevens suggestion of extending the schema to define a AdministrativePolicy element and a AdministrativePolicySet element. Would solve the problem nicely and be more intuitive to policy authors. https://lists.oasis-open.org/archives/xacml/201209/msg00001.html I am not concerned about changing the 3.0 schema. We can do the extensions only under the A & D Profile. Later if it seems desirable we can move it to core in a 3.1 or 4.0 version of core. Obviously there is no installed base to worry about. 95. Admin Profile: Handling XPath Category During Reduction Steven is correct, but the issue will go away with the introduction of Admin policy elements. 96. Admin Profile: Multiple Decision Requests during reduction I believe Erik is correct that the spec prohibits this from occurring, even though that fact may not be entirely evident. This also should go away with the resolution of Issue 94. 98. Admin Profile: Reduction should use Extended Indeterminate Values Steven is correct, new text is needed to address this, but the resolution is straightforward. 99. Admin Profile: Combining Algorithm on-permit-apply-second limits policy delegation I view this as a permanent restriction on this combining algorithm. (Doesn't work as expected with Admin policies.) This should be documented in A & D and also on the combining algs profile if current process allows it. 100. Admin Profile: Mysterious requirements text in section 2.2 Fixing this is straightforward. 101. Admin Profile: Sections 4.12 & 8.5 should discuss Advice as well as Obligations Fixing this is also straightforward. Is everyone with me so far? That just leaves: 97. Admin Profile: Revise reduction algorithm This is the main piece of work and since this is already long, I will start a new thread on this topic, which will assume the other issues have been resolved as indicated. Hal > -----Original Message----- > From: Steven Legg [mailto:steven.legg@viewds.com] > Sent: Monday, August 11, 2014 1:27 AM > To: Hal Lockhart > Cc: Erik Rissanen; xacml@lists.oasis-open.org > Subject: [xacml] 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- > s > > ignature-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- > deci > > sion-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 > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]