Subject: Re: Example in RBAC Profile is Out of Scope
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 makesthe example uninteresting. Perhaps you could do an x500Name-match of thesubject's subject-id/x500Name attribute value against the DN of the organizationto decide whether they are an employee, or an rfc882Name-match of the subject-id/rfc822Name against the organization's domain name ? Regards, Steven