[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Example in RBAC Profile is Out of Scope
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