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