[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]