[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: latest !!!!!!!!!!!!!!!!!!!!!!!!!!! (with an example)
Dear Argyn,Anne, Seth, 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 ?? 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. 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 ?? 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) 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 ?? <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> 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. 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. 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 ?? make sence ?? regards Muhammad.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]