Subject: Public Comment
Comment from: Aleksey_Studnev@exigengroup.com Anne, the proposed solution will work, but i notice the drawback of more complex construct. Every role is required to define special permission that it is role is granted. This seems a little excessive statement, because if role is granted to subject then it is evidently granted to subject. Also it opens another door for inconsistent policies where these statements are wrongly expressed or for Please consider the following solution: - To define role hierarchy you include permission for granting junior role (not permissions of role itself!) in permission set of senior roles. - You do not reference junior permission set from senior role There are at least benefits of this solution over current RBAC profile: 1) policy is consistent with RBAC description of inheritance users _and_ permissions. It is contrary to the proposed profile where this consustency must be ensured by extra efforts. 2) this solution does not mandate special handling of "permission policy sets" in a special way. In some sense current profile uses "permission policy sets" as role identitifaction which is a wrong approach. If role can not be identitifed by "permission policy set" then you can not reverse engineer XACML to RBAC. 3) it correctly handles requests such as "IsCallerInRole" with more simple policy definition than profile. Regards, Aleksey Anne Anderson <Anne.Anderson@Sun.COM> 05/19/2004 05:59 PM Please respond to Anne.Anderson@Sun.COM To Aleksey_Studnev@exigengroup.com cc email@example.com Subject Re: [xacml-comment] Public Comment On 19 May, firstname.lastname@example.org writes: [xacml-comment] Public Comment > i understand that if user request permission _other than > permission for role_ then your model works good. > > I mean a case if application needs to determine that user > granted a role. The real life cases include: > > 1) J2EE application invokes method isCallerInRole() which is > standard J2EE way for application-based access control. > > RBAC model implies role hierarchy for this. > > 2) If application needs entitlement information (say, for UI > customization). For example, show or not show UI > > controls depending of what user is entitled to > > 3) If application needs to determine what role(s) user is > graned - for audit, monitoring or other purposes. Thanks for this explanation. Now I think I understand what you are looking for. When you ask "isCallerInRole(X)", you are basically treating X as a resource, as in "Does caller have privileges associated with role X". I think you could model this in XACML RBAC as follows. In each Permission Policy Set, where role is "&role-value;X", add a policy of the following form (or equivalent predicate or MatchId). The policy creation tool could do this automatically. <Policy PolicyId="has:role" PCA="permit-overrides"> <Rule Effect="Permit"> <Condition FunctionId="and"> <Apply FunctionId="anyURI-is-in"> <AttributeValue DataType="anyURI">&role-value;X</AttributeValue> <ResourceAttributeDesignator AttributeId="&role;" DataType="anyURI"/> </Apply> <Apply FunctionId="string-is-in"> <AttributeValue DataType="string">hasPrivilegesOfRole</AttributeValue> <ActionAttributeDesignator AttributeId="action-id" DataType="string"/> </Apply> </Condition> </Rule> </Policy> Now, to ask whether "Aleksey" has role "&role;employee", submit the following request: <Request> <Subject>subject-id = "Aleksey"</Subject> <Resource>&role; = "&role-value;employee</Resource> <Action>action-id = "hasPrivilegesOfRole</Action> </Request> This request should follow the hierarchical role chaining and give the correct result. [Let me know if you need to have this written out in full XACML XML syntax] I haven't thought too much about this, so let me know if you see anything wrong with it. Thanks for the question. It stimulated some interesting thinking on my part. It may be worth adding this stuff to the XACML Profile for RBAC. 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 Note: When an application calls "isCallerInRole", the application is then taking on the functions of the access control system. In the case of associating certain options on a web page with a role, the application has those options (resources) associated with the role name, rather than asking the access control system whether the caller has access to each resource in turn. In the case of auditing of role assignments, this should probably not be done by the application, but by the AttributeAuthority or as part of the PDP decision making itself. The application, or the PEP, might want to audit that the caller got access to a particular resource.