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