[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, > >>> 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. :-( > > > > When a user asserts about some situation (e.g. Mallory asserts that > alice can use the printer), can he also constrain the situation i.e. > can he put some conditions too in a policy ?? > If he can put some conditions then, result can be deny as well, which > this profile simply dont allow. Profile states that "In case > <PolicyIssuer> element is present, > then combinining Algorithms that can result in "Deny" SHALL NOT be > used". ?? We have not worked out how deny results will work yet, so I cannot answer this. I am sorry if the profile in its current draft is a bit confusing. What we really mean for now is that you should use a permit-overrides algorithm and that the delegation processing model will treat a "deny" the same as "not applicable". Oh, btw, an another condition would make the result "deny", but "not applicable". > The point is that i am not going at all for ARBAC at all e.g. > user-role assignment, permission-role assignment and role-role > assignment. > I want that the Actors (e.g. Carol which in my case is represented by > role Manager) which can delegate can be represented by roles in order > to aggregate their rights based on their roles > If i am able to represent these usres/Actors by their roles, it will > easier for me to manage them rather than specifying delegation > policies for single users which is not at all handy in distributed > envoirnment. This is no problem. The examples in the profile are just examples. The Delegate in the target does not have to refer to a single individual. You can put an role attribute there instead. >> 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. > > > > The thing is that how we can combine these two policy sets i.e. RPS > and PPS. can i use an 'dont-care' Delegate element in the PPS so that > it shall match just to implement role hierarchy. Oh, I see now what you want. You want to add administrative rights for roles. There is no way right now in the profile to define a target that will match both access and administrative requests, so you cannot mix access rights and administarive rights in the same role using only a single policy set. For now, I suggest you create a second RPS for administrative rights, which can then refer to another PPS with the administrative rights. For this second RPS, you can use a empty Delegate element in the target, which will match any administrative request and then you can fill in the details in the PPS. I will add this issue to the open issues list. /Erik