OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Use Case

> Perhaps the confusion is with your definition of a "constraint".


> Here is an example.  Say a junior role's Permission PolicySet returns 
> "Permit" on access to resource X if the subject's "age" attribute is 
> greater than 21.  This is what I think of as a "constraint".
> If a senior role's Permission PolicySet references this junior role's 
> Permission PolicySet, then a holder of the senior role also will get a 
> result of "Permit" if the holder's "age" attribute is greater than 21.

This is really a simple constraint stating the age attribute. Assume some 
constraint which explictly specify the attributes of the junior role, that 
are not present with the senior role.
An example can be e.g. "Employees Processed orders". Now generally in the 
database, there are not orders with the managers, but only with employee. i 
am specifically talking about Xpath expressions e.g.

now these attributes dont exists at all for the caller i.e. Manager.
Now if , condition doesnot hold for the caller, it will simply cannot 

> But the senior role's Permission PolicySet could contain other rules that 
> return "Permit" if the holder's "age" attribute is less than 21.  A holder 
> of the senior role who is less than 21 will then get a result of "Permit" 
> on trying to access resource X even though a holder of the junior role 
> will not get such a result.

That is no problem.

> I don't see the inconsistency.  A constraint of this type specified for a 
> junior role applies to the senior role only in the case where the senior 
> role is inheriting that specific junior role permission.  It is not 
> inherited for any other permissions that the senior role may have or 
> inherit.

> Assume that, using the XACML RBAC model, the holder of a "Manager" role 
> inherits all the permissions associated with the "Employee" role by virtue 
> of the "Manager" Permission PolicySet including a reference to the 
> "Employee" Permission PolicySet.
> Then if there are constraints associated with a permission that is 
> associated with the "Employee" role, then a "Manager" will also get that 
> particular permission only if the "Manager" conforms to that constraint as 
> well.
> I think this is not correct.  Any constraints specified for particular 
> permissions from a junior role also apply to any senior role that inherits 
> that junior role's permissions.

Simply How ???

> I think you are trying to specify a permission that will be granted only 
> to direct holders of the role "Employee".  You do not want this permission 
> to be inherited by roles that are senior to the role "Employee".  Right? 
> You are saying that, unless someone has the direct role assignment 
> "Employee", there will not be a value for some Attribute required to 
> evaluate the "Complex Authorization Constraint".

No, i want that if constraint is specified only for junior role, that it 
shall be evaluated only for junior role, else it shall be evaulated for 
senior role.

> This will work, but I don't think you would like the results.  A "Manager" 
> will be able to do absolutely anything under any conditions whatsoever. 
> If this is what you want, why not just put <Rule Effect="Permit"/> 
> directly into the Manager Permission PolicySet?  It has nothing to do with 
> being an "Employee".

No Anne, you missed my point "If constraint is specified for the Role, then 
it shall be mentioned, otherwise, not.

your other solution that "If you want to give a permission to perform action 
X on resource Y to
Role Junior only if f(Role Junior attributes) is "true", AND you want to
give permission to perform action X on resource Y without those
constraints to Role Senior, which happens to inherit permissions from
Role Junior, then you need to include a rule in the Role Senior
Permission PolicySet that gives permission to perform action X on
resource Y (without any such constraints)."

This is not consistent with the profile at all.

Generalized constraints : i dont know, how in a real world, shall i find 
generalized constraints. There are always specilized constraints for 
specific roles


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]