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] retrieving a list or query filter of resources the caller is authorized for


Multiple profile is defined and implemented by some engines in XACML 2.0 as well.

Here is a solution that you might want to consider, but I'm not sure how pure it is from XACML point of view. Try to use obligation concept: the XAML resource in your solution should be a domain, not 2000 resources. The Obligation should be: "Show a list of all resources that this subject has access to". It's just an idea: I did something like that when was trying to implement "Display Authz Error Details" obligation. It was not easy, but doable. The policy might be complicated though with such an approach.

----- Original Message ----
From: "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>
To: Ralf Lorenz <rol@mms-dresden.de>; xacml-users@lists.oasis-open.org
Sent: Thu, April 15, 2010 6:11:41 AM
Subject: RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for

> -----Original Message-----
> From: Ralf Lorenz [mailto:rol@mms-dresden.de] 
> Sent: Thursday, April 15, 2010 04:30
> To: xacml-users@lists.oasis-open.org
> Subject: [xacml-users] retrieving a list or query filter of 
> resources the caller is authorized for
> Hey,
> several months ago I was asked to introduce a powerful rules-engine to
> generate authorizations into my current project. I had a look 
> around, found XACML
> and decided to try to use it.
> The result is an adaptation that is based on the XACML model.
> Being able to generate authorizations (spring-security ACL) 
> one of the main
> use cases is answering the question:
>   What secured resources (of a given type) is the given 
> subject authorized for?
> This includes the question what action is allowed for which 
> secured resource.
> I did not find a way to solve this problem with XACML itself.
> I understand that a PDP decides if a subject is authorized to 
> access a resource in some
> way whereas the subject, the resource and the action must be 
> given to the PDP
> but in some cases this is just not appropriate in my opinion 
> but I might be wrong;)

You only need to supply attributes in a specific category if your rules
require them to issue a decision.  So, if you haven't defined any action
types, and none of your rules test for action attributes, you do not
have to supply action attributes in the request.

> One of the basic requirements on the access control 
> management in my current project is to
> return a list of ids of secured resources of a certain type 
> to get that list from the
> related resource data store. To achieve that with XACML each 
> request to the PDP would
> include the complete list of secured resources the caller is 
> interested in and therefore
> it is necessary to always have all secured resources around 
> which often might be more than
> 2000.
> In my project I extended the PDP to have access to the domain 
> but this is probably not a solution
> in the sense of XACML but how about being able to return a 
> filter which can be used to query
> the domain?
> Any help on this issue and explanations in case I got 
> something wrong about XACML are welcome.

You have analysed it correctly.  The XACML specification only defines
the expected result of evaluating a policy set with respect to a given
request context.  The result of the evaluation, for an individual
request, is either "Permit", "Deny", "Not Applicable", "Indeterminate".

XACML 3.0 extends and clarifies the behavior of multiple decision
requests. (See the 3.0 Multiple Profile, which is in committee draft.

For your problem, you could submit a series of multiple decision
requests (or, if your PDP is 3.0 compliant, just one request with all
the subjects and resources).  From the results you can generate ACLs to
associate resources to subjects.  Depending on the volatility of your
subject and resource populations, this may or may not be practical.

I assume that your environment or architecture does not allow you to use
a XACML PEP to check access at runtime.  That would be the best
solution, but there are many situations where a PEP cannot be


To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-users-help@lists.oasis-open.org


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