[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]