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] Re: [xacml-users] XACML 2.0 Conformance TestsQuestions



On Thu, 2008-04-24 at 09:46 -0700, Oleg Gryb wrote:
> Ludwig,
> 
> Thanks for the answer, it's very helpful. I still have
> qs on multiple subjects and context handler.
> 
> 1. Context Handler.
> -------------------
> It looks like you consider context handler ability to
> fetch additional attributes as a mandatory XACML 2.0
> feature, but the only requirement to context handler
> that I found was this:
> 
> "...the context handler is responsible for obtaining
> and supplying the requested values by
> whatever means it deems appropriate."
> 
> In general "whatever" is not a very good specification
> if you look at it from implementation point of view
> and it doesn't mean at all that context handler MUST
> have a mechanizm for resolving attributes that are
> missing in request. I can say that my "whatever"
> mechanizm is to look for attributes in request message
> only. That's why I think that IIA002 should be
> probably included to PIP/PEP tests, not to PDP tests.

While I agree with you that this is only implied in the standard
(and not very well worded either), I would consider a PDP
that can only retrieve attributes from the Request of very 
limited value.

> 
> 2. Multiple Subjects in Request.
> ---------------------
> I think my qs was rather about understanding of
> concept  of multiple subjects in request than about
> evaluating algorithm. I actually think that evaluating
> algorithm in 7.5 doesn't match well intentions
> described in non-normative section 2.4. 
> 
> Let us look at example that you have: 3 subjects and
> only one of them matches <SaubjectMatch>. Decision
> "Permit" means that ALL subjects are authorized to
> have an access to the resource (does it?). Looks like
> a potential security breach to me, becuase I can add
> 100 more subjects with different categories to this
> request and they all will be granted a permission to
> the resource too.

The logic behind this functionality (as far as I understand) is this: 
If there are several subjects in the Request, they are trying to 
perform the access _together_ (in some way). There are now several 
options in the Policies:

1.) If any of the Subjects is allowed access alone, then access is
to be granted even if there are more Subjects participating ...

2.) ... unless you have a specific Policy denying those Subjects to
do the access together

3.) If you want to grant access only to those Subjects together, then
your Policy needs to reflect this.

If you want to Request access for several Subjects separately, you
should use one separate Request for each Subject.


Hope this helps,

Ludwig Seitz


-- 
Ludwig Seitz
Ph.D., Researcher
Security, Policy and Trust Laboratory (SPOT)
Swedish Institute of Computer Science (SICS)
homepage: http://www.sics.se/~ludwig


This is a digitally signed message part



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