[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Admin & Delg Profile new issues - 3
Yes, I see you are right. I misread the text. I have always thought of depth as a loop prevention control. I don't see admin-only as being that useful. I will close the issue. Hal > -----Original Message----- > From: Steven Legg [mailto:steven.legg@viewds.com] > Sent: Thursday, August 21, 2014 8:14 PM > To: Hal Lockhart; xacml@lists.oasis-open.org > Subject: Re: [xacml] Admin & Delg Profile new issues - 3 > > > Hi Hal, > > On 22/08/2014 5:01 AM, Hal Lockhart wrote: > > Delegating Access Policies only > > > > In section 5, just after Listing 1, the discussion suggests that the > > only way one can create an Admin policy that only permits the > delegate > > to create Access policies and not Admin policies is the use of > Maximum > > Delegation Depth. This can only work if the Issuer is aware of the > > number of levels of delegation which will occur prior to encountering > > the policy in question. (And that that number is constant.) > > I don't think that is true. Section 4.11 says the path length is from > the initial node which is being reduced (which I take to be the access > policy) and the policy with the MaxDelegationDepth attribute. So an > administrative policy with MaxDelegationDepth="1" is saying that the > policies it authorizes have to be access policies. The number of levels > of delegation leading to this administrative policy don't matter > (except to those administrative policies in the chain and their > settings for MaxDelegationDepth). > > > Further, under the current reduction algorithm, the limitations on > enforcement described in section 8.2 also may prevent this approach > from working as desired. > > > > I believe it is desirable to be able to create an Admin policy which > delegates Access policies only. I can also imagine wanting to allow > Admin policies only, but I can't think of a usecase off hand.I would > not ordinarily propose such a functional change at this late date, but > since the reduction algorithm is under reconsideration, I would like to > see this capability added if it can be done easily given whatever is > decided about the reduction algorithm. > > A MinDelegationDepth attribute could be defined to exclude access > policies at the next level, but I don't think it actually achieves > anything. We can't control who a delegate further delegates to. If we > insist that the next level does not contain access policies then the > delegate can get around that by creating an administrative policy that > authorizes an access policy issued by that delegate (i.e., delegating > to themselves). > > Regards, > Steven > > > > > Hal > > > > --------------------------------------------------------------------- > > 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]