[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] summary of Frank's delegation proposal
Got it. Thanks. -- Steve Anderson OpenNetwork -----Original Message----- From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] Sent: Tuesday, May 18, 2004 2:52 PM To: Steve Anderson Cc: XACML TC Subject: RE: [xacml] summary of Frank's delegation proposal On 18 May, Steve Anderson writes: RE: [xacml] summary of Frank's delegation proposal > In Round 2 of your Simple Example, shouldn't it be > Can Subjects D=Manager1 and S=Manager2 do Action A to Resource R? > rather than > Can Subjects D=Manager2 and S=Manager2 do Action A to Resource R? You are right. My typo. Thanks for the catch. > As far as that goes, I'm not clear why (according to Step 3b) > the new Subject corresponding to the Issuer is added to the > request, rather than replacing the previous Subject. In other > words (returning to Round 2 of the Simple Example), > > Can Subject D=Manager1 do Action A to Resource R? An Issuer who is delegating rights to another entity may limit the set of Subjects for which the delegate can issue valid policies. The delegate may not even be allowed to do things that the delegate is allowed to let other entities do. Anne > -----Original Message----- > From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] > Sent: Tuesday, May 18, 2004 2:21 PM > To: XACML TC > Subject: [xacml] summary of Frank's delegation proposal > > > For people who could not make the F2F, I thought I would > summarize Frank Siebenlist's proposal for delegation. I was > pretty excited by it, and this it may be a good approach. I > apologize to Frank if I am mis-representing his proposal! > > 1. Associate an Issuer with each XACML policy that is visible to > the PDP (i.e. not just in a SAML Policy Assertion). > > A new, optional <Issuer> element would be added as a child of > <Policy> and <PolicySet> to contain the Issuer identity. The > semantics of <Issuer> are that the named identity "says" that > the <Policy> or <PolicySet> in which it appears is an approved > policy of that identity. If the element is missing, the > Issuer is by default the PDP itself. > > 2. Allow an Issuer identity to declare that some other identity > has the right to issue policies of a given form. > > The other identity is specified by a Subject with a new > SubjectCategory meaning "can issue". > > 3. An additional step is added to policy evaluation to find a > chain of applicable policies such that Issuer = PDP. > > a. If the applicable policy has Issuer = PDP, then stop and > return the result of evaluating that policy. If there are > no applicable policies, return "Not Applicable". > > b. Otherwise, for each applicable policy, create a new Request > equal to the original request except that it has an > additional <Subject> with SubjectCategory="delegate" and > subject-id equal to the Issuer of the applicable policy. > > c. Find all policies applicable to the new Request. If any > result in "Permit", repeat starting with 3a. > > Simple Example: > > Policies are: > I is "Issuer" > D is a Subject with SubjectCategory="delegate" > S is a Subject with SubjectCategory="access-subject" > > 1. I=PDP > Permit Subject D="Manager1" to do Actions A to Resource R > > 2. I=Manager1 > Permit Subject S=Manager2 to do Action A to Resource R > > ROUND 1: > > Request: Can Subject Manager2 do Action A to Resource R? > > Policy 2 applies, and result is Permit, but Issuer is not PDP. > > ROUND 2: > > New Request: Can Subjects D=Manager2 and S=Manager2 do Action A > to Resource R? > > Policy 1 applies, result is Permit, and issuer is PDP. Return > Permit. > > Notes: > > Policies that include SubjectCategory="delegate" could be > constructed to limit the set of applicable Subjects with > SubjectCategory="access-subject", could apply to many > delegates, could apply to many resources and actions, etc. > > This delegation chain is only one policy long, but there could > be long chains. > > Policies might mix delegation permissions with non-delegation > permissions. For example, some rules might apply to a > particular Subject with SubjectCategory="delegate", whereas > others might apply only to access-subject Subjects. A single > rule could apply to a mixture. > > Things we did not finish thinking through (or that I did not hear > conclusions to): > > - Do all chains have to be evaluated every time, or is there some > caching that could be done? PDP could have limit on how long a > chain could be and could test for cycles. > - How are the new policies issued by entities other than the PDP > inserted into the policy evaluation? Could they be passed > along with a Request, and possibly limited to use with that one > Request? Is there some new PDP API? > - How do "Deny" policies fit into this model? > - Are any new combining algorithms useful or required? > > Anne > -- > Anne H. Anderson Email: Anne.Anderson@Sun.COM > Sun Microsystems Laboratories > 1 Network Drive,UBUR02-311 Tel: 781/442-0928 > Burlington, MA 01803-0902 USA Fax: 781/442-1692 > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. > -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]