Public Comment

[comment-form@oasis-open.org]

Comment from: Aleksey_Studnev@exigengroup.com

I have comments to a Draft 01 for RBAC implementation over XACML (cs-xacml-rbac-profile-01)
Comment 1:
Section 4.2 Hierarchical RBAC propose to model role hierarchy as (cite) "including a <PolicySetIdReference> to the Permission <PolicySet> associated with one role inside the
Permission <PolicySet> associated with another role.
XACML profile does not cover the full semantics of role hierarchy however. XACML profile does not fully cover the part of RBAC that senior role inherits permissions of junior role (explained below). XACML profile does not cover at all the second part that junior role inherits all users from senior part. 
There are several issues i see in this approach.
1) It is very hard to reverse-model role hierarchy from XACML profile in this way. So managing policy in terms of role hierarchy is lost. XACML profile gets only flat roles with permissions.
2) XACML profile does not cover the second part that junior role inherits all users from senior part
3) Some applications (say, J2EE security) uses methods such as isUserInRole(). XACML profile will not correctly work with the policy. (Is user is granted senior role,he will not be in junior role.)
4) Senior role must inherit all permissions from junior role. If XACML profile models roles as resources, then senior role must have permission for junior role as well. XACML profile does not grant it.

What i can propose as a solution to this issue is to change specification of Role hierarchy as:
Model role hierarchy as including a Rule granting junior role to the Permission <PolicySet> associated with senior role. As far as i can see this resolves all above mentioned issues because it explicitly states that senior role is granted junior role permission and (as consequense) all permissions related to it.

Comment2:
XACML profile makes RBAC possible only when using multiple PolicySet's. This makes a construct very complicated. Even Java 2 security makes hierarchical RBAC withing one file with much less exporessive power. I see the following issues here:
1) The construct is too complicated for managing. I hardly believe that administrator may manage RBAC policies in terms of XACML, he rather will prefer doing that in terms of roles themselves.
2) It is one-way. I want to make one-to-one relatiuon between RBAC semantics and XACML semantics.

I am not completely sure how to resolve issue 2, but this is my impression.

Thanks
Aleksey