[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 Tests Questions
--- Ludwig Seitz <ludwig@sics.se> wrote: > > 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. I would re-phrase your statements: an attribute-based authorization solution that can only retrieve attributes from a request has a very limited value. The difference is that I don't believe that attribute resolution should be necessary a PDP’s business. On contrary, I think that PDP is already complex enough, should be kept as puristic as possible and be isolated from other authorization solution (AS) components as much as possible. Here is an example on how this can be achieved. Transactional Service Consumer (TSC) - subject Transactional Service Provider (TSP) - attribute Transaction Count (TC) – attribute that is going to be resolved by AS, not by PDP Authorization must be made based on a number of transactions committed by TSC. TSC client will talk to PEP that takes two parameters only: TSC ID and TSP ID. PEP will enrich the request by sending it to an attribute resolver (PIP). Attribute resolver will add TC attribute to the initial request and send the enriched request to PDP that will rely only on attributes that are present in request to make an authorization decision. I think this approach will make my implementation of PDP more interoperable, because it doesn’t rely on a particular attribute resolution mechanism. If PDP were to make calls to attribute resolver then this PDP is bound to this particular implementation only and policies that are created for this PDP might not work with other PDPs that do attribute resolution differently. To summarize: I think it’s a good idea to get all attributes resolved before request hits a PDP. > > > > > 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 ... I think that this is grossly wrong from security point of view and should be reviewed by TC. Let us assume that I created an initial policy for a single subject where authorization solution is based on <SubjectMatch> only, e.g. I match a domain name against a regular expression and if authz decision is “Permit” I add this domain to “trusted domain” database. An intruder forged a request by adding yet another subject with a “rogue” domain name. As a result, the rogue domain becomes trusted. I do agree with you that a policy creator can avoid all this by creating more restrictive policies, but I think that not matching all subjects in request against a <SubjectMatch> in policy is a very dangerous and error prone feature that should be eliminated by adding additional restriction that is specific to requests with multiple subjects: “for rule, policy or policy set to be applicable to a request with multiple subjects each subject in the request must be matched against at least one <SubjectMatch>”. If you wish, it’s like “managed” and “unmanaged” code in programming. You do need “unmanaged” code e.g. to write device drivers, but for business applications “managed” code is a mainstream nowadays. I don’t see any practical motivation to have multiple subject authorization based on a single subject match only. If you have an example when it can be beneficial, please let me know. You’ll need to come up with a scenario when an access to resource for everyone must be granted based on a fact that the access has been granted to someone. > > 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 > > > ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]