[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
typo: you should read f(Subject,Resource,Action) instead of f(Subject,Resource,Attribute) and i would not mind to add yet another argument: policy/policyset ID, but it should not be the only argument... --- Oleg Gryb <oleg_gryb@yahoo.com> wrote: > > --- Ludwig Seitz <ludwig@sics.se> wrote: > > > Hi, > > > > I took the liberty to paste together your exchange > > with Seth > > and your answer to my mail, in order to try and > > clarify my point > > of view on both issues in one reply. > > > > > > > To summarize: I think it's a good idea to > get > > all > > > > > attributes resolved before request hits a > PDP. > > > > > > > > The problem is that this is an impossible > task. > > In > > > > all but the most > > > > closed and limited systems, it's a very hard > > task > > > > (in general) to know > > > > all attributes that will be useful for a given > > > > request. How do you know > > > > all attributes associated with the given user? > > How > > > > do you know what > > > > policies will apply to the request, which > > policies > > > > will be referenced > > > > as part of evaluation, and therefore which > > attribute > > > > values will be > > > > needed? > > > > > > I think, I know at least one person who can > answer > > all > > > these questions: this person is a policy > creator. > > If a > > > policy creator can't answer the qs about how > > (subject, > > > action, resource) vector (SAR) is mapped to > > attributes > > > that are required to do authorization job, then > I > > > would not trust much to this policy creator or > to > > her > > > policies. > > > > > > > Well I don't agree with this statement. As I see > it, > > this > > assumes that: > > > > a.) There is only one applicable policy per > request > > (and thus the policy creator doesn't need to be > > aware of others) > > OR > > b.) There is only one policy creator per resource > > (and thus the policy creator has sole control of > > all policies > > concerning the resource). > > > > Both of which are very unrealistic except in 'the > > most > > closed and limited systems'. Otherwise there is > > simply no > > way for the policy creator to know which > attributes > > are > > relevant (consider for example the creation of new > > attribute > > hierarchy relations after policy creation or > > attribute federation). > > Well, I think you should agree with a simple truth > that there is no a universal mechanism to resolve an > attribute. Moreover, I don't believe that there is > an > efficient way of binding a policy/policy set id to a > set of relevant "dynamic" attributes (I think this > is > what Seth suggested). So the attribute mapping > function is > f(Subject,Resource,Attribute)->Attributes > rather than f(Policy_ID) -> Attributes. > > It doesn't matter how many policy creators worked on > a > policy/policy set. They are still the single source > of > knowledge about what attributes they need and where > these attributes are stored. They will need to > communicate this knowledge to engineers who will > create adapters to get attributes from different > repositories. I still don't see a necessity to call > attribute resolution logic from inside of PDP. If > attribute model is changed, the adapters will need > to > reflect the change, no matter where the adapter is > called from (from inside PDP or outside of 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 don't think the XACML standard is wrong here, > > rather this seems to be a result of a erronous > > interpretation > > of both: > > > > a.) The trust model of access control > > > > If you can have untrusted PEPs in your system that > > can > > forge requests to PDPs, then there is not much > point > > in > > having access control at all, since the PEPs job > is > > to > > enforce access control decisions (a malicious PEP > > could > > simply ignore the PDP and give access without > === message truncated === ____________________________________________________________________________________ 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]