[cap-talk] distributed capabilities for models?
alan.karp at hp.com
Mon May 3 17:12:08 EDT 2004
Liang Fang wrote:
> Bascially we have two user roles here -- the resource owner
> and user. As
> a resource owner, more or less you have to be aware of the
> because you are the policy maker. You decide which part of
> the model is
> accessbile to your users.
Actually, this model doesn't work in practice because most service owners can't keep up with corporate policy. Instead, you want a third role, the policy administrator that hands out the capabilities. The service owner provides the capabilities to the policy administrator and says under what conditions to give them out. The policy administrator checks user credentials and hands out the appropriate capabilities.
> However, the resource users don't really have to
> be exposed
> to the capabilities. Usually we can hide the capabilities in
> the users'
> environment context, such as a portal context. Upon an
> invocation, the
> service client fetches the capabilites automatically from the user's
> context. The users may not even notice the existance of the
> at all.
This sounds dangerously like an ambient authority system. It's better to turn the user's acts of designation into acts of authorization.
> The security system can find the user's info (distinguished
> name ...) in
> the SOAP calls for auditing purpose.
You'll want to use something other than distinguished name. It's too hard to manage a dynamic user base across enterprise boundaries. Instead, you'll want to examine some property of the user, such as being an employee of a particular company or being in some particular role.
> This is really about the policy schema or language. Since it is the
> resource owner who issues the policies, the capability system may not
> care what policy schema is used, as long as the issuer himself
> understands his own policies. Even so, the capability system
> may provide
> some default authorizers according to some default policy schemas.
Exactly right. This approach lets the service evolve independently of the authentication/authorization mechanism.
Technical Computing Research Group
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp.vcf
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20040503/9867f9db/AlanHKarp.obj
More information about the cap-talk