Re: [xacml] A proposal for Context

[Polar Humenn <polar@syr.edu>]

On Mon, 6 May 2002, Simon Godik wrote:

> Polar,
> Do you mean this definition to apply to the attribute holder as well?
> Simon

That is part of the research I haven't really figured out yet. I am
assuming that one can associate attributes with a simple principal, i.e.
(P has [a1,...,an]), where P is a principal, and a1,...,an are privileges,
attributes, etc.

However, there are several other conditional authorizations that may be
formulated, such as

(P with [s1,...,s2] has [a1,...,an])

where s1,...,s2 may be a list of other attributes that P must obtain
before he is granted a1,...,an. This leaves the question open to whether P
is really a hardcoded principal, or a wild card, or that (P with
[s1,...,s2]) is just really a principal predicate.

It looks like we are currently taking the AttributeHolder to be closely
related to the X.509 Attribute Certificate, where the holder is merely a
name.

The question I think which is now on the table is whether we still
associate the Holder in the list of attributes in the ContextSubject, or
just the Attribute Values, as in your proposal.

The way I have done this in our CORBA security implemenation, is that it
is up to the Security Service (i.e.  the PEP in this case, which is also
the thing doing all the crypto, and signature validation) to forumlate the
correct Subject before giving it to the access control system. The reason
for this approach is that the client of the access control system already
has a concept of what the subject is and what its attributes are. It's no
good for the Access Control system to be thinking otherwise.

In CORBA what I have done is the structured principal concept, but every
Principal interface has a name, a list of attributes that the Security
Service has validated associated with the complex principal:

Lets take the case where we are a database and we get a request from our
WebServer that is actiing on behalf of Ernesto:

In my psuedo data structure lanaguage the client at the Database would
look like:

Client =
   ForPrincipal
      name = "Ernesto Damiani"
      privileges = [Group:D,Hospital:Doctor"];
      speaking = SimplePrincipal
                     name = "WebServer"
                     privileges = "Group:D"
                     alt_names = []
      speaking_For = SimplePrincipal
                     name = "Ernesto Daminani"
                     privileges = ["Hospital:Doctor"]
                     alt_names = ["rfc822:edamiani@crema.unimi.it"]

You can see here, that the name is lifted up from speaking_for because
most access control systems may not care about the intermediates, but
can dig for them if they want. Also, as far as the privileges go, the
security service as unioned them together due to some validation and
reconciliation of the authorization data, cyrptographic or otherwise.

This is done in the security service (I.e. the PEP), because you don't
want the Access Control system coming up with a different answer than what
the PEP did.

According to this approach, I would probably follow your protocol and
only consider attributes that are associated with the principal in
question, and elminate AttributeHolder in the ContextSubject.

Grouping Attributes under Principal as above might work better?

How do others feel about this approach?

Cheers,
-Polar



> ----- Original Message -----
> From: "Polar Humenn" <polar@syr.edu>
> To: "XACML" <xacml@lists.oasis-open.org>
> Sent: Monday, May 06, 2002 7:54 AM
> Subject: [xacml] A proposal for Context
>
>
> >
> > I have a small proposal on Simon's context.
> >
> > 1. We do not call the "subject" of the AuthorizationQuery the "Requestor".
> >
> > The "subject" of the authorization query is merely the subject, it is
> > not really requesting anything. I don't hold really hold to the idea
> > that the subject always "requesting access".
> >
> > I'd rather see the subject of the request be a structured principal, at
> > first, just one level, but later be able to be extended for more complex
> > principals.
> >
> > <x:Principal>
> > <x:NameIdentifier>....</x:NameIdentifier>
> > </xPrincipal>
> >
> > <x:SimplePrincipal>
> > <x:NameIdentifier>....</x:NameIdentifier>
> > <x:AlternateNames>
> >    <x:NameIdentifier>...<x:NameIdentifer>
> > </x:AlternateNames>
> > </x:SimplePrincipal>
> >
> >
> > and later on extend Principal to be Complex Principal, such as
> >
> > <x:ForPrincipal>
> >    <x:Speaking>
> >       <x:SimplePrincipal>....</x:SimplePrinipal>
> >    </x:Speacking>
> >    <x:SpeakingFor>
> >       <x:SimplePrincipal>....</x:SimplePrinipal>
> >    </x:SpeackingFor>
> > </x:ForPrincipal>
> >
> > Cheers,
> > -Polar
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
> >
>