Re: [xacml-dev] Some queries regarding RBAC and XACML Profile for delegation.

["Muhammad Masoom Alam" <Muhammad.alam@uibk.ac.at>]

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". ??


> 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.

by integration i simply meant to use XACML profile for RBAC for Rights 
delegation too.


> 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.

Agreed.


> 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.


I am working in the same direction

I will try to give the details of what i wanna do.

  "Suppose as in Profile Alice from Employee Group can print or can call 
print operation and it can be delegated by Carol. In order to make the use 
of Roles concept , we  say instead of Carol, Role Manager(where Carol has a 
role Manager) can delegate the situation i.e. Alice from Employee Group can 
call the Print operation where Carol has a role Manager.  Now if there is a 
role which inherits from Manager  Role, then the point is that he should 
also be able to do the same task as Manager can do"

 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.


>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.



regards,
Muhammad.