[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Absolutism or Relativism ? (was Re: [xacml] Issues with the Specification of Role Enablement)
Hi Erik, On 30/04/2014 4:54 PM, Erik Rissanen wrote:
It may be just simpler to remove the role enablement section, because role enablement can be done in many different ways, and this particular, non-normative example is confusing, and is unlikely to have any actual use.
I agree. Read on for a philosophical discussion. Hal showed some interest in where this was going. On 30/04/2014 4:54 PM, Erik Rissanen wrote:
Thanks, I think we agree on that the way role enablement is suggested in the non-normative section has potential problems and depending on the situation different solutions will be best. However, regarding having the role to be enabled in the subject category, that is in my opinion a violation of the spec. It says about <Attributes> that "The <Attributes> element specifies attributes of a subject, resource, action, environment or another category ..." http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html#_Toc325047149 The term "attribute" is defined in the glossary "Characteristic of a subject, resource, action or environment that may be referenced in a predicate or target (see also – named attribute)". I don't think this allows the possibility that an attribute may or may not be valid for the subject. It means that an attribute is a definitive statement of a characteristic. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html#_Toc325047067
Taken at face value, I find that neither of these references supports or refutes either of our positions because there is no linkage between the concepts of subject, resource, etc. and specific category URIs. I think you are applying an unstated assumption that the subject of a request must always be represented by the category with URI "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" (the access-subject category), the resource for a request must always be represented by the category with URI "urn:oasis:names:tc:xacml:3.0:attribute-category:resource" (the resource category), and so on for the action, environment and other entities of a request. For the sake of argument let me call that the Absolutist Point of View. That is, the idea that a given category URI fulfills a fixed purpose regardless of what kind of request we are talking about. Role enablement requests (the RBAC profile), obligation and advice requests (the OAA profile) and administrative requests (the administration and delegation profile) all need to refer to the attributes of an associated access request and all violate the Absolutist PoV in one way or another. In the case of the OAA profile it is a deliberate design decision to adhere to a different point of view. In the case of static role enablement, the access-subject is wrong. The entity that initiates a role enablement request, i.e., the subject for that request, is a component of the authorization system itself, not the person entity (for example) whose attributes appear in the access-subject category. One could argue that the authorization system is asking to enable a particular attribute value of the person entity, i.e., it is operating on the person entity, making the person entity the nominal resource for the role enablement request, in which case all of the attributes of the person entity should appear in the resource category instead of the access-subject category. If we take the more narrow view that we are acting on the role to be enabled as the resource, then the attributes of the person entity still don't belong in the access-subject category, so they would need to be in some new category for holding attributes of an entity that will be the subject of future access requests. In the case of dynamic role enablement, the access request is contemporaneous with the role enablement request and the role enablement request needs to contain the attributes of the access request in some form. Following the Absolutist PoV means that every category of the access request has to be mapped to a new category in the role enablement request because the fixed purposes of the original categories are fulfilled by different entities with respect to the role enablement request. Even the environment category needs to be mapped because the environment of the access request may not be the same as the environment of the role enablement request. The administration and delegation profile follows through on the idea of mapping the categories of the access request into new categories, when an administrative request is formed, by prefixing all the access request category URIs with "urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:" leaving the normal categories free for their specific purpose with respect to the administrative request. The subject for an administrative request is the PDP itself, but since there is nothing we particularly need to know about the PDP, the access-subject category of an administrative request is not populated. The action for an administrative request is always "reduction of a decision", so we can take that as a given and not bother populating the action category either. If the action is "reduction of a decision", then that suggests the nominal resource is the decision, but the administration and delegation profile puts it in the delegation-info category instead. That is where I think the administration and delegation profile deviates from the Absolutist PoV; it doesn't put the nominal resource entity in the resource category. Otherwise, it's fairly close. However, the method of prefixing the category URIs has some problems, which have been discussed previously. 1) Prefixing a URI with a URN does not necessarily produce a valid URI. 2) The prefixing has to be carried through everywhere category URIs appear, which means that values of the XPathCategory XML attribute have to be mapped too. 3) The specification has to address what it means if an access request uses the prefixed categories. Add to the list, that the resulting URIs are ugly and make the administrative policies harder to read and understand. For all those reasons I rejected prefixing as a solution for the OAA profile. Also because there is nothing disallowing OA administrative policies; double prefixing would have been really bad. I looked at other ways of doing the mapping, but not for long. The concept of category mapping was what was standing in the way of a simpler, more efficient and more easily understood solution. The category mapping came about because of the assumption that categories have the same purpose regardless of the kind of request, i.e, the Absolutist PoV. Break that assumption and everything becomes easier. So although the resource category is the nominal resource for an access request, it isn't for an OA request. The nominal resource for an OA request is described by the decision-info category instead. The resource category is still there in an OA request, but it is describing the nominal resource of the associated access request. The resource category is identical in both requests. If a need ever arose to represent attributes of a context handler as the subject of an OA request, then a new category can be created for that purpose and the access-subject category will continue to describe the subject of the associated access request. Likewise, if a need ever arose for more than an implied action for an OA request, then a new category can be created for that purpose and the action category will continue to describe the action of the associated access request. I will call the point of view taken by the OAA profile the Relativist PoV; the idea that the category URI corresponding to the nominal subject, resource, action or environment for a request depends on the kind of request being considered. Using the Relativist PoV we can say that delegation-info is the nominal resource of an administrative request. Or if someone prefers to think of it as the nominal action, or as some sort of combined resource-action-thingy, that is okay too. It no longer matters what we think it is as long as we are clear about how and when it is populated. However, the category mapping through URI prefixing is not in accord with the Relativist PoV. I'll come back to that shortly. Returning to role enablement, we don't have to worry about whether a person entity is the subject or resource of a role enablement request. We represent it in the access-subject category because it is the subject of an associated access request (a proposed subject of some future access request in the case of static role enablement). We can say that the access-subject category is the nominal resource for a role enablement request if we like. It's also alright to say that the nominal resource for a role enablement request is more specifically the value of the subject:role attribute in the access-subject category, but if it has to be in it's own category, then a category can defined for that purpose (rather than using the resource category because that is describing the resource of the associated access request). If we ever find a need to provide attributes of the subject or action of the role enablement request, then new categories can be defined for that purpose. A related topic is the methods by which we ensure that only access policies are evaluated for access requests, only role assignment policies are evaluated for role enablement requests, only OA policies are evaluated for OA requests, and only administrative policies are evaluated for administrative requests. For the OAA it is achieved by using a separate policy store. I proposed that to be the recommended method for role enablement as well. It's not a good choice for administrative requests because of the recursive nature of reduction. In addition to satisfying the Absolutist PoV, the category prefixing for administrative requests also ensures that only the right kind of policies are applicable for access requests and administrative requests. We previously had a discussion about using policy labelling to achieve the necessary separation while avoiding the complexities of category mapping and the problems of category prefixing. Policy labelling would also align administration and delegation with the Relativist PoV. The resource category in an administrative request would refer to the resource of the original access request. The delegation-info category in an administrative request is the nominal resource for the administrative request. The access- subject category in an administrative request would refer to the subject of the original access request. If we ever found the need to describe the PDP that is the subject for the administrative request, then we would define a new category for that purpose. A simple way to summarize the effect of the Relativist PoV is that it keeps the categories of the access request as is and adds new categories for the subject, resource, etc. of the subsequent role enablement request, OA request or administrative request. The Absolutist PoV requires that the categories of the access request be mapped into new categories so that the original categories are free to be used for their nominal purpose with respect to the subsequent role enablement request, OA request or administrative request. The former is simpler and more efficient than the latter and leads to policies that are easier to read and understand. Regards, Steven
I guess you could stretch it by defining a new attribute identifier which means "a role which the subject would like to asssert, but may not have the authority to do so". (BTW, I noticed that the glossary is marked as non-normative, which I would say is perhaps wrong because these terms are used throughout the spec.) Anyway, I would suggest that we table this discussion. It may be just simpler to remove the role enablement section, because role enablement can be done in many different ways, and this particular, non-normative example is confusing, and is unlikely to have any actual use. Best regards, Erik On 2014-04-30 07:15, Steven Legg wrote:Hi Erik, On 23/04/2014 6:00 PM, Erik Rissanen wrote:Hi Steve, Thanks for spotting the issue with collision with access policies. It's true that one cannot test for a category, so that text should be removed. I think the implied assumption regarding collision with access policies is that access policies should check whatever attributes they depend on and not make decisions unless the attributes of the request clearly mark the request to be an access policy about a situation which the policies are intended to handle. So I would propose that we change the text to this: "This separation may be managed in various ways, such as by using different PDPs with different policy stores or ensuring that any other policies present on the PDP do not make decisions on role assignment requests."That pushes implementors towards using the presence/absence of the enableRole value to achieve the separation, which is more of a burden on policy writers than using separate policy stores, as I've already argued.I think it is good to have the role attribute in the resource category, since conceptually the resource being requested access to is to enable the role.On the other hand, the effect of a successful role enablement check is to populate the subject:role attribute in the access-subject category, so referring to it by a different category in role assignment policies isn't exactly intuitive.The attributes of the subject should describe the attributes of the subject. If the role attribute is present on the subject category, the meaning of this should be that the subject has the indicated role, not that the subject is requesting access to the role.If the access-subject already has a value of the subject:role attribute does that mean a role enablement check should not be performed for that role value ? If a check is performed and the result is not Permit, does that mean the value should be removed from the access-subject ? What effect does that have on preceding role enablement checks that might have depended on the role values in the access-subject ? The profile doesn't provide any guidance on such questions. These questions don't arise if the role to be enabled is in the subject:role attribute of the access subject. A side benefit of leaving the subject:role where it is is that role assignment policies can unambiguously refer to role values to be enabled in the subject:role attribute of other subject categories, such as recipient-subject and intermediary-subject. I see no reason to disallow role enablement for other kinds of subject, but if they all map the role to be enabled into subject:role in the resource category, then the role assignment policies can't tell them apart. There would need to be a separate policy store for each category of subject.To implement dynamic role enablement, like you suggest, I think the more conceptually correct way to do it would be to define another category for it since such a request conceptually has these categories: - The current attributes of the subject - The requested role (this is the conceptual resource) - The context in which the role is intended to be used (the resource of the forthcoming access request)You missed two: the conceptual action and the action context in which the role is intended to be used. That is a viable solution, although it doesn't answer the questions above. Of course, the RBAC profile doesn't provide any category definitions to make this possible. You have two resource categories there. Which one gets to be "urn:oasis:names:tc:xacml:3.0:attribute-category:resource" ? I faced a similar consideration with the Obligation and Advice Authority. There I decided it would be clearer for policy writers to reference the resource and action attributes of the access request by their usual categories and let the extra resource (i.e., the decision) be in a new category. Separate policy stores meant I didn't need an extra action category. If the role to be enabled and the enableRole action are expected to be in new categories for dynamic role enablement, then it would make most sense for static role enablement requests to also use these same new categories.However, I think the end use case for something like this can be achieved more simply by considering the role to be statically assigned, and then checking any dynamic conditions as part of the normal access policies. Compare these two ways to implement the use case "The one who created a purchase order cannot approve it": - With dynamic roles: a) Check whether the subject as the approval role on the given purchase order. Deny this if the subject has created this purchase order. b) Do an access check to see if the subject as the approval role on the given purchase order. - With a separation of duties rule and static roles: a) Do an access check to see if the subject has the static approval role, and but deny if the subject had created the purchase order in question. The latter is in my opinion simpler since there is only a single request and single set of policies, which is easier to implement and understand since there is not this state to manage.I agree that using dynamic role enablement for separation of duties is more complex. It is also not a complete solution for XACML because it is based on the premise that users gain permissions through the roles they are assigned. In a general XACML system a user can gain permissions through policies that aren't related to roles in any way. For that reason I long ago discounted role enablement as a solution for enforcing separation of duties constraints. The profile would do better to not suggest a link between dynamic role enablement and separation of duties constraints as it does currently. Where I see role enablement being useful is in avoiding a role explosion. In a pure role-based access control system (where users only gain permissions through the roles they are assigned) the only way to deal with the inevitable exceptions and variations is to create ever more roles. Role enablement provides an alternative to that. For example, one can define a generic role for administering a particular kind of resource (Web portals, say) and then use dynamic role enablement to associate particular users with particular instances of the resource kind. The alternative is to define a separate role for each resource instance. Another example would be defining a generic role for a project leader and then using dynamic role enablement to only assign that role to project leader users when they are accessing the resources belonging to their project. Shift workers can be given a role appropriate to their duties that is only enabled during the hours of their shift. All these examples depend on dynamic role enablement. Static role enablement isn't worth worrying about, IMO, because it is too limited in what attributes it can safely use (the profile warrants a security considerations section pointing out the dangers of making static role enablement checks using attributes that are liable to change by the time of an access request).As such, I have doubts of the value of standardizing dynamic role enablement in this profile.Mostly I was arguing about the inadequacy of the specification of static role enablement. Segregation of the role assignment and access policies is the easier and simpler solution for static role enablement. That it can be defined to extend neatly and naturally to dynamic role enablement is a bonus. Regards, StevenBest regards, Erik On 2014-04-14 06:54, Steven Legg wrote:All, The way role enablement is defined in the RBAC profile is either underspecified, unsafe, or needlessly complex, depending on how one looks at it. For reference, a role enablement request is implied to have "urn:oasis:names:tc:xacml:2.0:actions:enableRole" as the value of the action-id attribute in the action category, and the URI of the role to be enabled as the value of the "urn:oasis:names:tc:xacml:2.0:subject:role" attribute in the resource category. Role assignment policies would be referring to these attributes. The profile suggests two methods to ensure that role assignment policies are only used when evaluating role enablement requests. It doesn't say that access policies are not to be used when evaluating role enablement requests, but I take that as a reasonable working assumption. The first method is to use a different PDP and different policy store for role enablement, i.e., to segregate the role assignment policies and access policies. The second method is to include an <Attributes> element with a Category of “urn:oasis:names:tc:xacml:2.0:subject-category:role-enablement-authority” in role enablement requests. However, a policy can't test for the presence of a category, it can only test for the presence of an attribute in that category. The profile hasn't defined such an attribute, reducing the likelihood of implementations being interoperable. If such an attribute were defined, then the "enableRole" value for the action-id attribute would be redundant since the presence of the new attribute indicates that a request is a role enablement request. An implementor might instead think to use the presence of the "enableRole" value of the action-id attribute in the request context to keep role assignment policies from being applicable during the evaluation of an access request. After all, it is simple enough to have a target like (action-id=="enableRole") for the role assignment policies. But the form of a role enablement request is not enough to prevent access policies from being applicable during the evaluation of a role enablement request. Consider an access policy that denied access to user "Bob". That policy would be applicable to every role enablement request for user "Bob", even though it's an access policy. In this case, the final outcome of any access request by "Bob" is probably as expected, but for the wrong reasons. If the same form of request were to be used for dynamic role enablement by populating the resource and action categories in the role enablement request with values from an access request, then many more access policies would be applicable during the evaluation of a role enablement request with much more unexpected results. To prevent access policies from being applicable during the evaluation of a role enablement request, a policy writer needs to express the negation of (action-id=="enableRole"), which isn't possible in a target. The policy writer would have to put the negated expression in the condition of every access rule, or use the on-permit-apply-second combining algorithm. Neither strategy is convenient, and even if the negation could be expressed in a target, it is still an imposition on the writers of access policies. Note that testing for an attribute in the "role-enablement-authority" category would have the same issues. Segregating the role assignment and access policies (the first method) is clearly a much simpler solution to support. In this case, the "enableRole" action-id value is unnecessary in a role enablement request or role assignment policy because any request directed at the PDP using the role assignment policies is implicitly a role enablement request. Likewise, any request directed at the PDP using the access policies is implicitly an access request. No additional assertions in the policy targets are required to keep the evaluation of access policies and role enablement policies separate. Putting the URI of the role to be enabled in the "subject:role" attribute in the resource category is also unnecessary. Putting it there opens the possibility that role assignment policies can test for the value of the "subject:role" attribute in the access-subject category (i.e., role enablement checks that are dependent on the outcome of other role enablement checks), which raises ordering dependencies on the role enablement checks. I don't think we need to go there. If instead the URI of the role to be enabled appears as the only value of the "subject:role" attribute in the access-subject category, then role enablement checks can't be dependent on the outcome of other role enablement checks and role assignment policies can then more naturally refer to the "subject:role" attribute in the access-subject category, which is the category and attribute the enabled role will appear in as far as the access policies are concerned. With the "enableRole" value gone and the "subject:role" attribute back in the access-subject category there is a clear and simple path for extending the profile into dynamic role enablement. The dynamic role enablement requests are just the access request with the "subject:role" attribute in the access-subject category taking each of the possible role values in turn (as it would for static role enablement requests). The action and resource attributes of the dynamic role enablement request are identical to the action and resource attributes of the access request. I think the RBAC profile should be recommending segregation for role assignment policies and dispensing with "enableRole" and the "subject:role" attribute in the resource category. Segregation is a superior solution for role enablement, whether static or dynamic. Regards, Steven --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]