[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] Some queries regarding RBAC and XACML Profile fordelegation.
Muhammad Masoom Alam wrote: > Hi Erik , > I hope i am not borring you? Hi Muhammad, > I have some queries regarding the latest Profile for Delegation of > XACML V7 > > > The first question is, whether an Issuer can Constrain the delegation, > or Delegation can only be constrained by Adminisration Policies. As > stated in Profile that "In case <PolicyIssuer> element is present, > then combinining Algorithms that can result in "Deny" SHALL NOT be > used". ?? I don't understand this question. Sorry. :-( > The 2nd question is that in the Administration Policy, uptil which > level we can constrain delegation e.g. in the Administration Policy it > can be specified that Carol can Delegate to Bob, by means of > DelegateAttributeDesignator and LaterDelegateAttributeDesignator. But > is this possible to further constrain that to whom Bob can delegate > further??. If we specify a new administration policy take Bob as > Delegatee, then what will be the value of the first policy in this > regard. I mean, if Bob can delegate to Mallory (by an Administraton > Policy), then there is no need to ask, that whether Bob is Authorized > himself or not?? and on the other hand, if we can constrain multiple > level of delegation, then it makes a long chain isnt so? The <LaterDelegate> element of the request context is for this. The <DelegateAttributeDesignator> is used to constrain that Carol can only delegate to Bob. The <LaterDelegateAttributeDesignator> is used to constrain to whom Bob can further delegate. You can use <LaterDelegateAttributeDesignator> in a condition, thus constraining the further delegation. The exact details of <LaterDelegate> are not explored yet. It should be possible to refer to them using the higher order functions of XACML, but I haven't tried out the details yet. Also, the <LaterDelegate> elements should perhaps be ordered, to permit more detailed conditions, if so desired. (BTW in the next draft, LaterDelegate will change its name to IndirectDelegate.) > Another issue is the integration of RBAC Profile for XACML with this > delegation Profile. > e.g. i have Role A, and Role B and Role B is super > Role of Role A so how his inheritence relationship works in XACML profile > -- There will a Role Policy Set (RPS) for > every Role e.g. A & B > -- There will be Permission Policy Set > (PPS) for every Role too. > -- Now, RPS will only contains Role > Definition and will reference PPS e.g. As Role B is the super Role of > Role A, there fore, RPS of B will refer to its PPS and then PPS of B > will refer to PPS of Role A , to make this inheritence relationship > in the XACML. I don't understand your example (quoted below). The first policy set has an unbalanced Policy element, and I am not sure how you intended it to be. According to the RBAC profile there is no Policy element in the RPS, so I assume that the target is really for the PolicySet. But in that case, your policies will not match any request, since the top level target has a delegate element and the nested policy set's target does not have it. Also, I am not sure what you mean when you say "integrate" with the RBAC profile. "Integration" could refer to a number of delegation related features and RBAC. One feature of integration would be that if someone has been delegated the right to create access permissions, then he should be able to organize those permissions with the RBAC model. This should work. He will simply be the issuer of the RPSs, and the access requests that are permitted by his RBAC policies will be authorized by the administrative policies as usual. Another level of integration with delegation would be to look at how the management of the RBAC permissions could be delegated. RBAC has three operations: user-role assignment, permission-role assignment and role-role assignment. For each of these, we can imagine that the right to perform the opertation could be delegated and that different people could be doing each of the operations. Since user-role assignment is done by means of an attribute assignment, it really falls outside the scope of XACML. I have worked on this issue and I have ideas for how to do it, but I haven't tried them out yet. In my opinion, delegation of attribute assignment is important in a delegated access control system, and might be something that XACML could support in the future, but this is nothing that has to my knowledge ever been discussed in the XACML TC. When it comes to role-role and role-permission assignment, the delegation profile doesn't go very well with RBAC. The problem lies in that RBAC is fundamentally based around the role concept in how it constrains administrative operations. The delegation profile is on the other hand based on the source of authority for a resource. The RBAC administrative models ask "will this operation violate the desired properties of the role hiearchy?", while the XACML delegation profile asks "has this issuer been authorized to allow this access?". These views are fundamentally different and cannot be easily reconciled. For instance, in RBAC the act to add a resource to a role must be perfomed by the a role administrator with autority over the _role_, while in the delegation profile it has to be done by an administrator with authority over the _resource_. I find the latter approach more correct, since in a distributed and decentralized system we cannot assume that role administrators are the same people as the resource owners. This also means that in the model on which the delegation draft is based, it is possible for someone to add permissions to roles created by other people, which is not possible in classic administrative RBAC. This might first seem a bit weird, but when you think about it, it's really how things are in a distributed system by nature. If I say that you have "attribute X", then I cannot really prevent other people from saying that "if you have attribute X, then you can use my resource". (At least as long as the attribute X is publicly available. I could try to keep it secret.) A summary of this long answer would be that: someone writing access policies in a delegated environment can do so be means of the RBAC profile, but the administrative operations of ARBAC don't really map to the delegation profile. Though I haven't really worked on this yet. Personally I think that the ARBAC is not the right solution since it assumes that the role owners have authority over all resources too. Also, the ARBAC role hierarchy really mixes two kinds of hierarchies: the is-a relation and the administrative authority. They should be separate. RBAC02 is moving in this direction by starting to separate the two. In the delegation profile they are already separate: the administrative hierarchy is implemented in the delegation hierarchy and the is-a hierarchy is implementd with the nested policy sets. Anyway, I am interested in this, so keep us posted. Regards, Erik > Now considering the same for Delegation Profile > > i think so > > we can have RPS like this > > <PolicySet> > > <Policy PolicyId="RPS_Role_B" > RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> > > <Target> > <AnySubject/> > <AnyResource/> > <AnyActioin/> > > <Delegates> > <Delegate> > <DelegateMatch > MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> > <AttributeValue > DataType="http://www.w3.org/2001/XMLSchema#string">RoleB</AttributeValue> > <DelegateAttributeDesignator > AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" > DataType="http://www.w3.org/2001/XMLSchema#string"/> > </DelegateMatch> > </Delegate> > </Delegates> > </Target> > > <PolicySetIDreference> PPS_OF_RoleB </PolicySetIDReference> > </PolicySet> > > > and then PPS of Role B will contain the Definition of actual > permission with a reference to PPS of role A since it is the super > Role. make sence ?? > > <PolicySet> > <Policy PolicyId="Policy PPS_OF_RoleB" > RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> > > <Target> > <Subjects> > <Subject> > <SubjectMatch > MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> > <AttributeValueDataType=http://www.w3.org/2001/XMLSchema#string > >> employee</AttributeValue> > > <SubjectAttributeDesignator > AttributeId="group" > DataType="http://www.w3.org/2001/XMLSchema#string"/> > </SubjectMatch> > </Subject> > </Subjects> > <Resources> > <Resource> > <ResourceMatch > MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> > <AttributeValue > DataType="http://www.w3.org/2001/XMLSchema#string">printer</AttributeValue> > > <ResourceAttributeDesignator > AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" > DataType="http://www.w3.org/2001/XMLSchema#string"/> > </ResourceMatch> > </Resource> > </Resources> > <Actions> <Action> > <ActionMatch > MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> > <AttributeValue > DataType="http://www.w3.org/2001/XMLSchema#string">print</AttributeValue> > <ActionAttributeDesignator > AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" > DataType="http://www.w3.org/2001/XMLSchema#string"/> > </ActionMatch> > </Action> > </Actions> > </Target> > <Rule RuleId="Rule1" Effect="Permit"> > <Target> > <Subjects><AnySubject/></Subjects> > <Resources><AnyResource/></Resources> > <Actions><AnyAction/></Actions> > </Target> > </Rule> > <PolicySetIdReference> PPS_OF_ROle_A </PolicySetIdReference> > > </PolicySet> > > The thing is that RPS will only contains the Delegate element and will > reference the PPS where as PPS will contains permission and > additionally a referece to another PPS for inheritence relationship. > > > I hope i was able to convey my idea. > with Best regards > Muhammad. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]