MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] A proposal for Context
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
>