Re: [xacml] Issues with the Specification of Role Enablement

[Erik Rissanen <erik@axiomatics.com>]

Hi Steven,

Thanks, this is a lot to parse and clearly some work remains to be done. 
I suggest that we let the RBAC profile fall behind the rest, like we did 
for the admin profile, and vote the rest of them forward on today's call.

Best 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