[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:
> 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
> bothering
> forging a request in the first place).
>
> b.) The semantics of a request with multiple
> subjects in
> XACML
>
> In your example you still interpret this request as
> if
> all subjects where given access separately. This is
> not
> the semantics of an XACML request with multiple
> subjects.
> Since my previous explanations seems to have been
> unclear,
> I hope my example later in this mail will be more
> understandable.
A short example:
1. A policy creator created a rule that matches a
domain name coming in subject against a regular
expression *.oasis-open.org.
2. An engineer that builds an enforcement point
noticed that the traffic on his web application is
very big and decided to increase authz system
performance by combining multiple subjects in a single
XACM request.
3. The outcome of this solution: each time when
oasis-open.org is in the list of subjects, the
permission will be granted to all of them.
I dont believe that n of k authorization will be
implemented very often. It means that a policy creator
will mostly think in terms of a single subject,
forgetting about the backdoor that he opens for other
subjects that could be included to the same request.
What is the difference between access is granted to
all subjects jointly or access is granted to all
subjects differently in this case? The policy creator
was thinking about one subject when he was creating a
policy. PEP implementer sent multiple subjects to
improve performance. The decision is Permit. How the
authorization service consumer should interpret it?
All Im saying is that its error prone and very
confusing for a policy creator, a PEP implementer and
an authorizationi service consumer.
> > 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.
>
> I will build one based on grid computing, using an
> XACML
> shorthand to keep the examples short:
>
> There are three services S1,S2,S3 executing
> different tasks
> on behalf of a user U in the grid (this is expressed
> in XACML
> by a subject category that I called
> "intermediary-agent").
> Both S2 and S3 are used by S1 to execute subtasks.
> However
> due to an incorrect interface usage, S1 is calling
> on S3
> excessively. Since the admins of S1 have not been
> able to fix
> this, the admins of S3 have created a policy denying
> S1 access
> to S3. Otherwise the user U has access to all three
> services
>
What will you put to the XACM request s subjects? All
4 entities (U, S1-2-3)? How are you going to build
your SubjectMatch rule? Based on 'U' subject only? If
its based on one subject match only, then my example
(see above) is still valid: a PEP creator can build
enforcement point that will pass multiple subjects to
PDP and the backdoor will be opened again.
If it's not convincing, consider yet another scenario:
I will pass (U, S4, S5, S6) where the latter three
should not have access to the resource. If you build
your SubjectMatch based on U only the permission will
be jointly granted to (U, S4, S5, S6) and it's not
what you wanted.
____________________________________________________________________________________
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]