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: Re: [xacml-users] RE: [xacml-dev] RBAC Profile for XACML


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.



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; 
>>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 
>>Policy Set) Where, RPS contains the role definition (RoleName) and 
>>references to PPPS and PPPS contains the actual permission 
>>with a rule (if 
>>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 = 
>>            <PolicySet Combining Algorithm = "permit-overrides">
>>            </PolicySet>
>>            <Target>
>>                Role Definition
>>            </Target>
>>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.
>>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]