OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml-dev] XACML and Constrained RBAC


Hi Helmut,

Thanks for the response. Please find my comment below...

On Thu, Oct 27, 2011 at 8:07 PM, Helmut Petritsch <helmut@petritsch.co.at> wrote:
Hi Fatih,

if I would need to implement DSoD as defined in RBAC, I would introduce
something like a session into XACML, i.e., implement a mechanism similar
to cookies in HTTP (HTTP is stateless, too). A PAP would allow to create
a new session: he returns a unique identifier to the client (i.e., PEP)
which then sends this unique ID with every request. Furthermore, the PAP
would allow to assign information to this session, e.g., roles which the
user is permitted to assign. If the PDP needs to get some information
out of the "session", the attribute designator would read the unique
session ID from the request context, and use this ID to query the PAP
(or a common component) about the required information. The DSoD rules
would be enforced at the PAP, i.e., the user cannot assign another rule
to the session if it would violate the DSoD constraint.

I guess we have to clarify (my mistake) that for supporting
DSoD, as you also pointed out in your example, you don't need to store the system state.
DSoD only requires the knowledge of what happened (better to say did event A happened?). So
basically it is not necessary to know all history ({s1,..,sn}) of states but whether the relevant event
happened at some point of time... 

Anyways, apparently there is no implementation, at least from list members, that supports
such a functionality e.g. DSoD enforcement.
 

However, the real point I wanted to make is: XACML is very powerful,
thus, I would use the power of XACML instead of reimplementing a
mechanism which is bar far not as powerful as what XACML is able to
provide.


King regards,
 Helmut


On 10/27/2011 07:32 PM, Fatih Turkmen wrote:
> Hi Helmut,
>
> Thanks for your message. Yes in fact, without sessions DSoD can not be
> supported and its suuport heavily depends on sessions. You are also
> right that
> sessions are application (better to say domain) dependent...
>
> I was exactly referring to the point you highlighted : stateful PDP.
> Actually I
> would rather say stateful XACML (instead of XACML PDP) because the state
> can/must be supported at different levels/components of the XACML
> implementation.
>
> There are several approaches, including extensions to XACML language or
> using OWL
> ontologies for satisfaction, however I don't know any concrete XACML
> implementation
> available.
>
> Thanks again for your response.
>
> --
> Fatih Turkmen
> Web: http://sites.google.com/site/fturkmen/
>
> On Thu, Oct 27, 2011 at 11:04 AM, Helmut Petritsch
> <helmut@petritsch.co.at <mailto:helmut@petritsch.co.at>> wrote:
>
>     Hi Fatih,
>
>     I think the first question is, if there is an implementation which
>     supports RBAC out of the box. Even the XACML RBAC profile does not make
>     any statement about the user assignment, bot only defines the
>     (equivalent) to the permission assignment. For my understanding, RBAC
>     and especially Constrained RBAC with DSoD relies heavily on the concept
>     of sessions, which on the other hand needs some integration into the
>     application landscape. E.g., this could be implemented with a PAP which
>     allows to add roles to a session and a PIP which queries the current
>     roles assigned to a session. And, you need to introduce the concept of a
>     session for the stateless XACML PDP.
>
>     However, I think XACML allows you to model more powerful DSoD
>     constraints in a much simpler way. For example, to model the SoD in a
>     travel request (i.e., the one who is requesting a travel may not be the
>     one who approves the travel request) you can use a condition. A permit
>     rule allows a manager to approve travel requests, but the condition
>     excludes the case where attribute subject-id and attribute requestor are
>     equal, i.e., in a simplified form, the xacml rule could look like
>
>     <Rule Effect="Permit">
>      <Target>
>      <Action>approve</Action>
>      <Resource>TravelRequest</Resource>
>      <Role>manager</Role>
>      </Target>
>      <Condition FunctionId="not">
>      <Apply FunctionId="string-equal">
>       <Attribute>subject-id</Attribute>
>       <Attribute>requestor</Attribute>
>      </Apply>
>      </Condition>
>     </Rule>
>
>     I know, this is not a direct answer to your question, but hopefully it
>     helps anyway...
>
>     Regards,
>      Helmut
>
>     On 10/26/2011 10:24 PM, Fatih Turkmen wrote:
>     > Hi all,
>     >
>     > I am mostly aware of the scientific literature about XACML and its
>     > extensions
>     > (both architecturally and syntactically) for Constrained RBAC.
>     However,
>     > is there
>     > any XACML implementation (i.e. PDP, PEP etc) that supports for
>     instance
>     > Dynamic Separation of Duty (DSoD) out of box and perhaps
>     accessible somehow?
>     >
>     > Thanks in advance.
>     >
>     > --
>     > Fatih Turkmen
>     > Web: http://sites.google.com/site/fturkmen/
>     >
>
>
>
>



--
Fatih Turkmen
Web: http://sites.google.com/site/fturkmen/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]