Re: ClientAuthentication questions

Mark Brouwer wrote:
> In some cases you don't know all the
> principals in advance (PKIX TrustManager) or it doesn't scale very well
> if you have hundreds of thousands of clients (which is not quite
> uncommon in a PKI infrastructure) and you have to grant permissions for
> each of them.

This is one of the reasons why I created a PAM authentication module that works
with JAAS.  I wanted to be able to allow anyone who had an account on the
machine, to have general access to the services.  I've done this two distinctly
different ways.  I've talked about these in the past in various ways.  The
https://pastion.dev.java.net/ project has the code that I've used, in various forms.

I created a new BasicInvocationDispatcher and BasicInvocationHandler which
passed down the "login" identity (an ssl endpoint makes sense in doing this).
During each remote call, PAM login is invoked, and only successful logins
proceed.  The associated Subject is activated to allow further control.

The other mechanism, is a java.lang.reflect.InvocationHandler which is
associated with a java.lang.reflect.Proxy object which is created by a remote
method call which the RemoteIdentity is passed into.  This factory mechanism
makes it possible to hold the identity locally so that it is on the wire less
frequently.

public MyService getService( RemoteIdentity id ) {
        InvocationHandler ih = new RemoteInvocationHandler(
                id, this, lgnCtxName );
        MyService is = (MyService)Proxy.newProxyInstance(
                id.getClass().getClassLoader(),
                new Class[]{ MyService.class },
                ih );
        // Get an exporter for this user
        Exporter exp = getExporter( id );
        return (MyService)exp.export( is );
}

> In case I'm correct would be the path to follow is extending
> BasicInvocationDispatcher and override checkAccess() and then do
> whatever I need to do to express that kind of permissions, which
> probably means that I will bypass the usage of a security policy
> based access control mechanism altogether and also go for access
> permissions that can work on a more granular level, i.e. can
> differentiate between methods that have the same name but differ in
> parameters[1].
>
> [1] anyone felt the need to control access permissions on a more
> granular level than what is currently available through
> AccessPermission, if so please let it know.

I still have some code that I've wanted to get out which takes a policy
expressed by the description of each method and it's parameters.  Policy can be
assigned based on the value of particular parameters.  In its current form, it
uses ACLs and explicit policy checks in that regard.

I'd like to recast this concept into a new set of tools which would read an
interface, generate the XML text that my tools understand, and then rewrite the
code generator to use Policy based control instead.

This stuff was designed, to be used with a delegation pattern so that you could
simply wrap an existing object with this delegating proxy to addon security.

I'd like to recast it into an exporter that would allow deployers to add on
method based policies by instantiating the exporter with a pointer to the
"policy descriptions".

Gregg Wonderly

--------------------------------------------------------------------------
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]