river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: PAM - Pluggable Authentication Modules Any Ideas?
Date Mon, 17 May 2010 14:45:47 GMT
You can not safely authenticate anything to execute locally using remote 
software and "knowledge".  PAM should be used on the service's local 
environment.  JERI provides support for this in the invocation layer factory. 
There is an example shown in the http://pastion.dev.java.net project's
org.wonderly.jini.jaas.jeri package.

What happens with this code, is that a Subject based call is made on the remote, 
client side using a RemoteIdentity instance.  The PrincipalInvocationHandler 
will extract it and pass it through the JERI transport to the 
PrincipalDispatcher which will authenticate each call using the RemoteIdentity. 
  The RemoteIdentity, as a Principal, can then be used for authorization through 
policy management.

Gregg Wonderly

Peter Firmstone wrote:
> Gregg Wonderly wrote:
>> Craig L Russell wrote:
>>> Hi Gregg,
>>> On May 13, 2010, at 8:23 AM, Gregg Wonderly wrote:
>>>> If you use System.load(), then you can use a static initialization 
>>>> block to copy the jni bits from the jar into a temp directory and 
>>>> then load it from that path.
>>> My understanding is that you need to start the VM with the knowledge 
>>> of where all the jni libraries are. You can either put them into the 
>>> "standard" place (varies by platform) or in a special place and name 
>>> that special directory using the -Djava.library.path system property 
>>> when you start the VM. It doesn't work to set the system property 
>>> after you start the VM.
>> System.loadLibrary() does behave this way.  System.load() does not, 
>> and can load from anywhere providing permissions are granted 
>> appropriately.
>> Gregg Wonderly
> Hmm, some ideas, or am I barking up the wrong tree?
> Could we not use a smart proxy that utilised System.load() to copy the 
> PAM JNI pieces locally as Gregg suggests, we could, as part of the next 
> release sign our jar files, then the code could be trusted and filtered 
> and permissions granted based on the signer principal.
> The interfaces for interacting with the proxy could also be downloadable 
> and be loaded safely into a top level ClassLoader, all clients can 
> utilise a PAM Service Interface. Entry's could be used to identify the 
> platform each PAM service is specific to.
> Perhaps PAM at the clients could be dynamically updated, work on 
> existing Jini clients and be specific to each platform.
> Or is this just too complicated?  Is there something similar that might 
> work?  Sorry just thinking about cross platform issues.
> I'm working on an new interface to perform dynamic permission grants 
> based on a CodeSource and Principal's, similar to static grants and in 
> addition to class (ProtectionDomain) and Principal grants for proxy's.
> It's also revokeable, so that if a CodeSource becomes compromised the 
> Permission can be removed dynamically too.  A CodeSource can have 
> multiple ProtectionDomain's.
> The trick to making a Permission revokeable is to not allow the 
> PermissionCollection to become merged with the static 
> PermissionCollection in the ProtectionDomain.  This means alway's 
> utilising the Java 1.4 + non static constructor in PermissionDomain.
> Regards,
> Peter.
>>>> Associated permissions need to be granted of course.
>>> Of course.
>>> Craig
>>>> Gregg Wonderly
>>>> Sent from my iPad
>>>> On May 13, 2010, at 9:59 AM, Dennis Reedy <dennis.reedy@gmail.com>

>>>> wrote:
>>>>> On May 12, 2010, at 714PM, Peter Firmstone wrote:
>>>>>> I like the sound of that.
>>>>>> We can have an Authentication Service, we could place the 
>>>>>> constraint of a key signature on that particular service (don't 
>>>>>> want untrusted parties providing authentication), but once loaded,

>>>>>> the smart proxy could contain the JNI code required to perform the

>>>>>> authentication?
>>>>> I'm not really sure if (and how) a smart proxy that once download 
>>>>> can (or should be given permission to) load a native library. From 
>>>>> what I have seen, the native library needs to be loaded from a 
>>>>> location that the JVM knows about (a priori). Would that native 
>>>>> library need to be installed onto the machine to the location where 
>>>>> the JVM has been configured to load native libraries from before 
>>>>> that native library was loaded?
>>>>> Would the native library need to be loaded by a class loader that 
>>>>> is hierarchically a parent of class loaders that load services? 
>>>>> This is because the same JNI native library cannot be loaded into 
>>>>> more than one class loader, but different child class loaders of a 
>>>>> class loader that loaded the JNI library can gain access to the 
>>>>> loaded library such that System.loadLibrary will succeed (this 
>>>>> naturally assumes that other class loaders in the JVM would want 
>>>>> the capability to load the native library).
>>>>> Dennis
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!

View raw message