Re: [xacml-dev] Re: [xacml-users] XACML 2.0 Conformance Tests Questions

[Oleg Gryb <oleg_gryb@yahoo.com>]

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