Re: ClientAuthentication questions

Mark Brouwer wrote:
> Hi Gregg,
>
> Gregg Wonderly wrote:
>
>> 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.
>
> I can't recall all the details, but I believe the client subject (as per
> Jini security) was also restored by the dispatcher as the subject
> executing the remote method invocation, this is something that I don't
> want to do.

Yes, in my case, I chose to activate that Subject.  My implementation of policy
and code structure, comming into the server, provides the right level of
controls for access to the JVM resources via codesource based permissions.  The
Subject activation, then allows the application level permission checks to be
done using the Subject's granted permissions.

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?

>>> [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.
>
> With 'value' I guess you really mean value and not type. If so than this
> is where I don't want to go now because for me it feels that access
> control based on values as parts of remote method invocations is
> something that I would consider application layer security and something
> that seems to be very hard in a declarative way.

Yes, specifically value.  The XML document structure that I have, lets you
specify security based on lots of different scenarios.  Behind the scenes is the
following details.

There are resource types that you define, which match onto the types of values
that exist in the API.  So, for example, I might have a "view" resource type.
Each resource type can be controlled with "edit/delete", "read" and "admin"
access types.

So, a policy might be created for a method with the signature:

public void configureView( String name, ViewInfo cfg );

The method policy might say:

<method return="void" name="configureView" qualifiers="public">
        <security>
                <limit type="view" access="edit" arg="name"/>
        </security>
        <args>
                <arg name="name" type="String"/>
                <arg name="cfg" type="ViewInfo"/>
        </args>
        <exceptions>
                <throws name="SQLException"
                        descr="if a database access error occurs"/>
        </exceptions>
</method>

Now, the toolset uses this XML to generate interfaces, and the delegate which
embodies the security model.  There is an invisible backing store associated
with the implementation of the policy that the generate code knows how to use.

There's a GUI component which allows the configuration to be managed.  Because
of the parameterization, most of it is data drive. Not a small amount of
software, but it is fairly simple minded.

I wrote this to run on jdk1.1.8.  I'd like to rearchitect it to use a
java.lang.reflect.InvocationHandler instead, embedded in an Exporter
implementation, as I said.

> It is a pity that there is no standard (that I'm aware of) that allows
> adding attributes to a X500Principal that could be stored as part of the
> public certificate (or associated with it) and that could be utilized by
> a framework or application for the purpose of access control checks. You
> end up all the time inventing your own extensions for this :-(
>
>> 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.
>
> With Policy you mean security policy, in that case you likely end up
> (again) with the inability to express "all trusted principals are
> allowed to invoke this method".

There is the ability to say

        <security>
                <user access="read" via="*"/>
        </security>

which means all known users.  There is the ability to deny users a particular
permission, instead of granting it.

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]