Re: Example in RBAC Profile is Out of Scope

[Steven Legg <steven.legg@viewds.com>]

Hi Erik,

On 8/04/2014 7:52 PM, Erik Rissanen wrote:
> Hi Steven,
>
> I don't think there is a problem with this example. What section 1.7 says is that the role is provided externally, and is independently assigned from the policies which are then evaluated based on the role. I don't think the example violates this.

It's not a violation, but it is unwise because it makes the role assignments
very sensitive to the time at which the roles are enabled and that can easily
lead to incorrect access decisions.

> Sure, the time might change between the role is enabled and the access condition is checked, but so can any attribute which is used to enable roles, including membership in an organization.

Those other attributes aren't constantly varying. The roles have to be
assigned at some time and an implementation of static role enablement
could (in fact, should) limit role assignment polices to assertions over
stored attributes of access subjects and choose to recalculate a subject's
roles whenever there is a change to the subject's stored attributes. In
that way the roles are always correct at the time access requests are
checked and the outcome is exactly the same as if the roles were
actually dynamically enabled.

I wonder, would you accept a context handler that looked up the current
time only when it started and then reported that exact same value for the
current-time attribute for every subsequent access request that the PDP
processes ? You seem accepting of something equally bad for static role
enablement.

> If this is a concern, the role enabling and the access check should be done in a joint transaction with consistent use of attribute values.

Well then you are talking about (what I would define as) dynamic role
enablement, which is supposedly out of scope. If the profile has
pretensions of being applicable to dynamic role enablement as well,
then I find it seriously lacking. See my other email on the RBAC profile.

Regards,
Steven

> I would leave the example as it is. Or did I misunderstand what you meant?
>
> Best regards,
> Erik
>
>
> On 2014-04-04 06:08, Steven Legg wrote:
> > Hi Erik,
> >
> > Section 1.7 of the RBAC profile has this to say about the scope:
> >
> >     "The policies specified in this profile assume all the roles for a given subject
> >      have already been enabled at the time an authorization decision is requested.
> >      They do not deal with an environment in which roles must be enabled dynamically
> >      based on the resource or actions a subject is attempting to perform."
> >
> > Yet the Role Assignment policy in the example of Section 3 is dependent on
> > the current time, which means it can only correctly assign roles if they are
> > enabled dynamically. The example should be changed to depend on some property
> > of the subjects that doesn't vary from one access request to the next. The
> > simplest change would be to remove the check for time of day, though it makes
> > the example uninteresting. Perhaps you could do an x500Name-match of the
> > subject's subject-id/x500Name attribute value against the DN of the organization
> > to decide whether they are an employee, or an rfc882Name-match of the
> > subject-id/rfc822Name against the organization's domain name ?
> >
> > Regards,
> > Steven