Re: ClientAuthentication questions

Gregg Wonderly wrote:

> Bob and I had some discussion about this on the list last time I brought
> it up,
> and he was in the same camp as you about not doing this.  Maybe you can
> also
> share why you don't want to do this to help document the use cases/issues?

I'm aware the general idea of JAAS was to do it this way, but I never
found its authorization part very intuitive or fit for its task. The
subject was for me always a sort of thread local variable I could
utilize for access control decisions, often involving external systems.
Never did I use policy files for this purpose as to me these are most of
the times static (there is a dynamic one these days but that one doesn't
allow for revocation of permissions). Another drawback is that you
likely have to define loads of custom (often complex) permissions and
I'm concerned about the scalability of security policies in general.

I think it is much easier to code an access control mechanism based on
the identity found in the subject and the 'permissions' stored somewhere
else (LDAP or whatever), or as part of the Principal. And large
organization often had some sort of central entitlement system that you
needed to consult anyway. The fact that you were able with to carry a
subject as part of the execution path was great, at least much better
than an additional argument for every method call.

For me a Jini service as an entity that is capable of performing certain
tasks, such as deleting all the files on your hard disk. It doesn't
loose or gain capabilities based on the client who asks to perform a
task, the service just should tell whether it wants to perform a certain
task for a client, but at all times its intrinsic capabilities stay the
same.

A reason that might make more sense is that you rely on a
SecurityException to pop-up somewhere if a client is not allowed to
perform a certain action. As this is an unchecked exceptions I fear that
it is very easy to make mistakes when you build up state along the
execution path. A way to prevent from that is to perform security check
at the start of each operation, but in that case it seems you have it at
the same place as any other custom mechanism.

In general I tend to grant AllPermission to the codebase of a server
that I trust (although some of my examples proof the opposite), and only
a minimum to the mobile code. Granting AllPermission to the codebase of
a server leaves no ability to grant permissions to a particular
principal as it implies all permissions. In case of a remote method
invocation I assume the permissions will be the combination of those
associated with the Subject and with the protection domain of the
server, or do you manipulate the AccessControlContext effective in a
particular way?

Hope this helps Gregg, don't get me wrong that I think it is wrong to do
it the other way, it is just that I can't find intuitive.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]