[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re: alternative "isCallerInRole" implementation/model
On 11 June, Aleksey Studnev writes: re: alternative "isCallerInRole" implementation/model > the main question is "But how did the PEP know that role > "Employee" was the one to ask for? ". The solution i used is > to use special function "role-is-granted" > > <SubjectMatch MatchId="urn:sea:role:is-granted"> > <AttributeValue > DataType="http://www.w3.org/2001/XMLSchema#anyURI";> > urn:xacml:sea:policy:role:Admin</AttributeValue> > <SubjectAttributeDesignator > AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" > DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> > </SubjectMatch> > > and this function delegates this check to PEP which in turn > asks for RolePermission. > > Complete sequence in runtime is: > 1) Application asks PEP for access resource > 2) PEP asks PDP for the decision about resource access. It > makes request with subject, resource attrs, action e.g. subject-id == "Aleksey" > 3) PDP finds policy for the resource and iterate over xacml > Rules. In the rule it finds SubjectMatch as above > 4) PDP invokes role:is-granted function. If role is active for > the subject, it returns true. If it is not active, function > delegates this call to PEP by requesting role > activation. In this sense PDP works here as application on > step 1. Now the sequense will again recursively start from > step 1 (role now is resource). XACML functions do not work that way. Before the "urn:sea:role:is-granted" function is called, the <SubjectAttributeDesignator> will have already been evaluated. Functions do not get "raw" arguments - they get evaluated arguments. The PDP will ask its ContextHandler for AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role", which effectively asks for all "role" Attributes associated with a subject-id of "Aleksey". The ContextHandler will not know that it needs to check to see if resource-id "urn:xacml:sea:policy:role:Admin" action-id "is-granted" to subject-id="Aleksey". Anne > So application and PEP does not need to know "which specific > (non-hierarchical) roles are required for access to a given > resource/action" > > On 10 June, Anne Anderson writes: > > > Regarding > > http://lists.oasis-open.org/archives/xacml-comment/200406/msg00000.html > > > > Step 1 in the model you describe might indeed be used by an > > Attribute Authority, and could be used to answer questions like > > "isSubjectInRole(<role>,<subject-id>). [The XACML Profile for > > RBAC can also be used to answer this question, as I showed in > > http://lists.oasis-open.org/archives/xacml-comment/200405/msg00009.html] > > > > I do not think the model you describe is a good model for role > > based access control, however. > > > > 1) It requires the PEP to know which specific (non-hierarchical) > > roles are required for access to a given resource/action. > > This embeds policy into the application (PEP), while the goal > > of policy-based access control is to allow policy to be > > separate from the application. > > > > 2) It puts the responsibility for determining role hierarchies > > into the hands of the Role Assignment/Activation Point (RAP), > > and not in the hands of the resource's Policy Administration > > Point (PAP). My model of RBAC is intended to allow these two > > functions to be separate: the RAP knows which direct roles to > > assign to which specific people, the other PAP knows which > > direct roles are associated with which access rights and is > > free to arrange roles hierarchically to better manage these > > associations. > > > > As an example, using your model, assume subject "Aleksey" has > > role "Manager", which is senior to role "Employee". Assume role > > "Employee" is required to "read" file "/a/b/c". > > > > When "Aleksey" attempts to "read" file "/a/b/c", the PEP will > > intercept this request. In your model, the PEP must first ask > > the PDP whether "Aleksey" has the role "Employee". > > > > But how did the PEP know that role "Employee" was the one to ask > > for? It must be because the PEP has that information stored: "if > > user asks to 'read' file 'a/b/c', the user must have role > > 'Employee'". And that means policy is embedded into the > > application. If the Policy Administration Point later decides > > that an "Employee" can't 'read' file '/a/b/c', but only a > > "Financial Officer", then the application itself must be changed, > > and not just the XACML Policy. > > > > The XACML Profile for Role Based Access Control (newest draft at > > http://www.oasis-open.org/committees/download.php/6806/wd-xacml-rbac-profile-02.1.pdf > > ) > > is intended to separate policy from the application. The > > application (and PEP) only needs to know which direct roles are > > enabled for a Subject, and which resource/action are being > > attempted by the Subject. Even the direct role information can > > be off-loaded to the PDP. > > > > On 1 June, Aleksey Studnev writes: > > > this is absolutely correct. > > > > > > On 1 June, Anne Anderson writes: > > > > I am still trying to understand your RBAC model. I believe use > > > > of RBAC in your model requires two steps: > > > > > > > > 1) Ask the PDP if the Subject has a given role enabled. There is > > > > a collection of policies that answers this question, and this > > > > collection supports hierarchies of roles. > > > > > > > > 2) Using the given role now as a Subject Attribute, ask if the > > > > Subject has permission to do some particular action on some > > > > particular resource. The collection of policies for answering > > > > this question is not hierarchical, so you have to ask the > > > > question using the right role value. > > > > > > > > Is this correct? -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]