[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-users] RE: [xacml-dev] RBAC Profile for XACML
Muhammad, Thanks, Argyn! This is a great explanation for what seems to be the major issue in Muhammad's use case. There is one more subtle issue that I would like to mention since Muhammad's original e-mail showed a "DenyPolicy". The ANSI Standard RBAC model, which the XACML RBAC Profile follows, uses only positive permissions: there are no "Deny" rules. If you read the Ferraiolo, et al. RBAC book, there is no mention of negative permissions. Because we were just following the ANSI RBAC model, the XACML RBAC Profile does not state that "Deny" rules should not be used, and this is probably not clear to everyone. It will be in a future erratum. The problem is that, with ANSI-style hierarchical inheritance, if you put a "Deny" rule in the PPS for a junior role, then that "Deny" rule will be inherited by every senior role that inherits from that junior role. In general, with "Deny" semantics, you want a "Deny" to propagate downward to less powerful roles, but not upward to more powerful roles. With the ANSI model of roles, however, you can't do that, so you simply can't use "Deny" Rules and maintain overall consistency. I haven't investigated this issue completely, and I am interested in feedback. I think it would be possible to put a "Deny" rule in a RPS that uses the "Permit-overrides" combining algorithm to achieve a default result of "Deny" (assuming no Rule in the PPS hierarchy returned "Permit"). But I think that is about as far as you can go with Effect="Deny" or FunctionId="...:not" usages in the ANSI/XACML hierarchical RBAC model. Comments? Anne Kuketayev, Argyn (Contractor) wrote: > your RPS looks a little unusual to me. MY RPSs have only one function, > which is to reference appropriate PPS. As such they have only the target > (to identify who's assigned this role) and policyset reference to PPS. > > In your case you have also PolicySet element within RPS. Please, read > the latest RBAC profile doc ch. 1.5 paragraph 1. This is the excerpt > from the doc: > > === > 1. Role <PolicySet> or RPS : a <PolicySet> that associates holders of a > given role attribute and > value with a Permission <PolicySet> that contains the actual permissions > associated with the given > role. The <Target> element of a Role <PolicySet> limits the > applicability of the <PolicySet> > to subjects holding the associated role attribute and value. Each Role > <PolicySet> references a > single corresponding Permission <PolicySet> but does not contain or > reference any other > <Policy> or <PolicySet> elements. > === > > Your RPS doesn't comply with this. Look at the sample RPS and PPS in the > doc. > > Thanks, > argyn > > > > >>-----Original Message----- >>From: Muhammad Masoom Alam [mailto:Muhammad.alam@uibk.ac.at] >>Sent: Thursday, June 09, 2005 3:56 AM >>To: Seth Proctor; xacml-dev@lists.oasis-open.org; >>sunxacml-discuss@lists.sourceforge.net; >>xacml-users@lists.oasis-open.org >>Cc: Seth Proctor >>Subject: [xacml-dev] RBAC Profile for XACML >> >> >>Hi Seth and all, >> >>i am stuck again into XACML profile for RBAC. >> >> According to RBAC, we have RPS (Role Policy Set) and PPPS >>(Permission >>Policy Set) Where, RPS contains the role definition (RoleName) and >>references to PPPS and PPPS contains the actual permission >>with a rule (if >>any). >>Now considor i have a Role A , which have two permissions >>associated with >>it, one is Positive Permission Policy Set(PPPS) and one is >>NegativePermission Policy Set (NPPS). >> >>The structure of the Role Policy set is (as you described in >>one of your >>email is ),this is some simplified XACML. >> >> >> <PolicySet PolicySetId="RPS:RoleA" Combining Algorithm = >>"deny-overrides"> >> >> <PolicySet Combining Algorithm = "permit-overrides"> >> >> >><PolicySetIdReference>PPPS:RoleA</PolicySetIdReference> >> >> >><PolicySetIdReference>DenyPolicy</PolicySetIdReference> >> >> </PolicySet> >> >> >> <Target> >> >> Role Definition >> >> </Target> >> >> >><PolicySetIdReference>NPPS:RoleA</PolicySetIdReference> >> >> >></PolicySet> >> >> >>now considor RoleA inherits from RoleB some permissions , >>there fore, the >>PPPS:RoleA will contains a reference to the PPPS of RoleB >>(i.e. PPPS:RoleB). if generally, there is no rule applicable >>to RoleA in the PPPS of RoleB, a >>general "DenyPolicy" (from the Role Policy Set) will be >>applicable which is >>not a right behaviour, since RoleA inherits from RoleB, and >>if there is no >>rule applicable in the inherited Role permission policy set >>(PPPS:RoleB), it >>shall give permit (if NPPS:RoleA is not applicable or gives true). >> >> >>am i right ?? >>if yes, what can be the other solutions. >> >> >>regards >>Muhammad. >> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org >>For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org >> >> > > > --------------------------------------------------------------------- > 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]