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: Re: [xacml-users] latest !!!!!!!!!!!!!!!!!!!!!!!!!!! (with an example)


Muhammad Masoom Alam wrote:
> you are not getting my point at all, the thing is that negative 
> permissions or policies are not a problem at all, the problem is the 
> inheritence of the constraints , i.e. if a constraint is specified for a 
> junior role, does this apply to the senior role as well or not ??

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.

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.

> if yes, then the problem starts, if the constraint is specified for a 
> junior role explicitly, then it a problem, we have to some where in the 
> Permission policy set mention that which constraint is applicable on 
> which role , but this is not consistent with the XACML Profile for RBAC.

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.

> An example can be " A Manager inherits all the permission with the Role 
> Employee, (with or without constraint ??), if with, there are 
> constraints which are explicit for employee role, in that case , role 
> manager will automatically get rejected, since that constraint was 
> explicit for role employee. now in the permisison policy of employee, 
> some where we have to mention that which constraint is for which role.). 
> Agreed ??

It is hard for me to parse this sentence.  See if the following 
interpretation is consistent with what you are trying to say:

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.

> now this time, all the policies are according to the Profile
> 
> 
> 
> look,
> 
> so let me tell you the background again.
> 
>  A seniour Role inherits a permission from Junior Role "without" the
> constraints which are specified for the Junior Role (unless explicitly
> specified). (This what i think uptil now)

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.
> 
> if we say " A seniour role inherits a permission from Junior Role "with" 
> the
> constraints which are specified for the Junior Role, then for simple
> constraints e.g. Date, Time values, it makes sence, but it doesnot make
> sence for the constraints explictly specified only for the Junior Role. 
> This is the main point do u agree with this or not ??

I don't know what you mean by "constraints explicitly specified only for 
the Junior Role".  Any constraints in any inherited Permission 
PolicySets are inherited for the permissions in those specific 
Permission PolicySets by the senior role.

> 
> <PolicySet PolicySetId="RPS:managerRole" Combining Algorithm 
> ="permit-overrides">
>           <Target>
>                Role Definition
>            </Target>
> 
>                    
> <PolicySetIdReference>PPPS:managerRole</PolicySetIdReference>
> 
>          </PolicySet>
> 
> 
>                                                        First Permission
> Policy set for managerRole
> 
> <PolicySet PolicySetId="PPPS:managerRole" Combining Algorithm =
> "permit-overrides">
>    <Policy Combining Algorithm = "permit-overrides"  PolicyId =
> "Permissions:for:Role:managerRole"
>            <Rule Effect="Permit">
>                       <Condition>
>                            A Simple Authorization Constraint based on
> time/date
>                        </Condition>
>                </Rule>
> <PolicySetIdReference>PPPS:employeeRole</PolicySetIdReference>
> </PolicySet>
> 
>                                                                2nd PPS for
> employee:
> 
> <PolicySet PolicySetId="PPPS:employeeRole" Combining Algorithm =
> "permit-overrides">
>    <Policy Combining Algorithm = "permit-overrides"  PolicyId =
> "Permissions:for:Role:employeeRole"
>            <Rule Effect="Permit">
>                       <Condition>
>                            Complex Authorization Constraint based on some
> Attributes from Database for the Role Employee only.
>                        </Condition>
>                </Rule>
> </PolicySet>


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

In this case, when the "Complex Authorization Constraint" is evaluated, 
there will be no value for that particular Attribute.  This causes the 
Rule to be NotApplicable or Indeterminate (depending on how that 
Attribute is referenced).  In either case, the senior role will not get 
that particular "Employee" role Permission if standard Combining 
Algorithms are used.

Alternatively, you could include a reference to this particular, 
non-inheritable Permission PolicySet directly in the Employee Role 
PolicySet, since it is not part of the hierarchical roles.
> 
> Now , considor that, the Authorizaiton constraint specified in the
> "PPPS:employeeRole" is not a simple authorization constraint, i means which
> refers to some database values, for employeeRole only, now as there is no
> Target (stated by RBAC Profile) in line 194-197
> what will be the result of this rule, as ManagerRole doesnot possess the
> attributes specfied in the Authorizaiton constraint of the
> "PPPS:EmployeeRole" , if the result  is NotApplicable,  the behaviour is 
> not
> consistent with the Profile.

Because an "Employee" would get the permission, but the senior "Manager" 
would not, even though the "Manager" inherits the "Employee" 
permissions?  This is not inconsistent with the PRofile.  Any 
constraints other than holding a role must still be satisfied by the 
requester: role inheritance rules do not override all other constraints.

> If the result is not applicable : "Does we have to put some Rules again in
> the PPS  (of the junior Role) to mention that if non of the rules are
> applicable then the result will be Permit (since seniour role inherits the
> permissions of the junior role" otherwise, if we dont put any rule
> explicitly, the problem  that, there is a general DenyPolicy (see above 
> RPS)
> in the RPS, which will make the whole result deny if the result is
> Deny/NotApplicable.

I've lost you here.  Are you saying you want a "Manager" to get the 
"Employee" permission even though the "Manager" does not have some 
Attribute necessary to qualify for the "Employee" permission?  That has 
to be handled outside of the role hierarchy: you would have to give the 
"Manager" that permission in the "Manager" Permission PolicySet in such 
a way that the Attribute is not required.

If a particular Attribute is required to get a particular Permission, 
and a requester does not have that Attribute, then the requester should 
not get that Permission, regardless of role inheritance.
> 
> 
>            My Propsed solution :
> 
> 
> e.g.
> <PolicySet PolicySetId="PPPS:employeeRole" Combining Algorithm =
> "permit-overrides">
>    <Policy Combining Algorithm = "permit-overrides"  PolicyId =
> "Permissions:for:Role:employeeRole"
>    <Rule id="1" Effect = "Permit">
>     <Target>
>             Role Name (of the seniour Role e.g. ManagerRole)
>      </Target>
>    </Rule>
>            <Rule id="2" Effect="Permit">
>                       <Condition>
>                           Complex Authorization Constraint based on some
> Attributes from Database for the Role Employee only.
>                        </Condition>
>                </Rule>
> </PolicySet>
> 
> 
> 
> Now rule 1 is for all the senior Roles (ManagerRole), n Rule 2  is only 
> for Employee 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".

> make sence ??

No, it doesn't.

Regards,
Anne

> regards
> Muhammad.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
> 

-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA


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