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 <> wrote:

> 
> --- Ludwig Seitz <> 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