Re: Example in RBAC Profile is Out of Scope

[Erik Rissanen <erik@axiomatics.com>]

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. 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. 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.

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