You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/05/11 07:06:22 UTC
PAM - Pluggable Authentication Modules Any Ideas?
Anyone got any ideas for PAM in Apache River?
Regards,
Peter.
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dennis Reedy wrote:
> On May 13, 2010, at 531PM, Gregg Wonderly wrote:
>
>> Dennis Reedy wrote:
>>> On May 13, 2010, at 1123AM, 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. Associated permissions need to be granted of
>>>> course.
>>>>
>>> Sure, you can copy the native lib to a temp directory, and assuming you
>>> have set the JVM up to load native libs from that directory that would
>>> work, but you still need to address the class loader issue right?
>> There are no requirements for "setting up the JVM" except for permissions needed when you use System.load() as opposed to the less flexible System.loadLibrary(). So, any code with appropriate permissions granted can use System.load() to load a dynamic library which will bind with JNI class definition.
>
> FWIW, in my experience dealing with native libraries it gets very very tricky
> if you want different class loaders to use the same loaded native library.
> So *any* code is generally subjective based on the class loader, is not just
> the permissions.
I had not spoken about this issue as I was trying to recall the details. I have
not had problems with ServiceStarter based services launched in the same JVM
using my class for authentication of each service. I need to run some test to
make sure that I am recalling, correctly, what I have experienced.
>>> I think that you'd rather want to have the native libraries required for
>>> authentication part of your 'platform'.
>>
>> As the service provider, you want the authentication to happen correctly.
>>
>> I don't want to lead on that a client would be using a JNI JAAS authentication
>> implementation locally. But, I wanted to point out that System.load() works
>> fine. I have my JAAS authentication in a utilities jar.
>
> What classloader loads your utlities.jar?
The PreferredClassLoader that is created by the ServiceDescriptor.create() call
is loading the service classes. I need to check to make sure I am not
misremembering how many services are using this facilitiy per JVM.
>> My authentication class loads the .so from the file system, using System.load()
>> to load it, with no properties set in the JVM to indicate where libraries
are at.
>> It would work just fine to use ClassLoader.getResource() to find the library
>> (even using the os.name or some such property to pick the appropriate one),
>> copy it out the the filesystem and load it from a different, more random path.
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Dennis Reedy <de...@gmail.com>.
On May 13, 2010, at 531PM, Gregg Wonderly wrote:
> Dennis Reedy wrote:
>> On May 13, 2010, at 1123AM, 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. Associated permissions need to be granted of
> >>course.
>>>
>> Sure, you can copy the native lib to a temp directory, and assuming you
> > have set the JVM up to load native libs from that directory that would
> > work, but you still need to address the class loader issue right?
>
> There are no requirements for "setting up the JVM" except for permissions needed when you use System.load() as opposed to the less flexible System.loadLibrary(). So, any code with appropriate permissions granted can use System.load() to load a dynamic library which will bind with JNI class definition.
FWIW, in my experience dealing with native libraries it gets very very tricky if you want different class loaders to use the same loaded native library. So *any* code is generally subjective based on the class loader, is not just the permissions.
>
>> I think that you'd rather want to have the native libraries required for
> > authentication part of your 'platform'.
>
> As the service provider, you want the authentication to happen correctly. I don't want to lead on that a client would be using a JNI JAAS authentication implementation locally. But, I wanted to point out that System.load() works fine. I have my JAAS authentication in a utilities jar.
What classloader loads your utlities.jar?
> My authentication class loads the .so from the file system, using System.load() to load it, with no properties set in the JVM to indicate where libraries are at. It would work just fine to use ClassLoader.getResource() to find the library (even using the os.name or some such property to pick the appropriate one), copy it out the the filesystem and load it from a different, more random path.
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dennis Reedy wrote:
> On May 13, 2010, at 1123AM, 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. Associated permissions need to be granted of
>>course.
>>
>
> Sure, you can copy the native lib to a temp directory, and assuming you
> have set the JVM up to load native libs from that directory that would
> work, but you still need to address the class loader issue right?
There are no requirements for "setting up the JVM" except for permissions needed
when you use System.load() as opposed to the less flexible System.loadLibrary().
So, any code with appropriate permissions granted can use System.load() to
load a dynamic library which will bind with JNI class definition.
> I think that you'd rather want to have the native libraries required for
> authentication part of your 'platform'.
As the service provider, you want the authentication to happen correctly. I
don't want to lead on that a client would be using a JNI JAAS authentication
implementation locally. But, I wanted to point out that System.load() works
fine. I have my JAAS authentication in a utilities jar. My authentication class
loads the .so from the file system, using System.load() to load it, with no
properties set in the JVM to indicate where libraries are at. It would work
just fine to use ClassLoader.getResource() to find the library (even using the
os.name or some such property to pick the appropriate one), copy it out the the
filesystem and load it from a different, more random path.
Gregg Wonderly
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Dennis Reedy <de...@gmail.com>.
On May 13, 2010, at 1123AM, 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. Associated permissions need to be granted of course.
>
Sure, you can copy the native lib to a temp directory, and assuming you have set the JVM up to load native libs from that directory that would work, but you still need to address the class loader issue right?
I think that you'd rather want to have the native libraries required for authentication part of your 'platform'.
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim, Thanks for the info, after brief review, JNA looks like a much
better replacement for JNI, it can access native libraries directly from
Java, so would reduce maintenance and C multi platform Make file issues
associated with JNI.
JNA is available at https://jna.dev.java.net/
It is licensed under LGPL v2.1 or later, so can be a platform
requirement, although we cannot distribute it with River, we can write
code utilising it.
Looks like we can utilise JNA proxy's to write library calls for PAM on
Unix / POSIX / Linux / BSD / OSX etc and something different on
Windows. Need something to wrap them up in like an SPI.
Cheers,
Peter.
Sim IJskes - QCG wrote:
> On 13-05-10 18:49, Craig L Russell wrote:
>> 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.
>
> We could study how JNA solved this. It looks like a very deployment
> friendly solution for native bindings.
>
> Gr. Sim
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 13-05-10 18:49, Craig L Russell wrote:
> 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.
We could study how JNA solved this. It looks like a very deployment
friendly solution for native bindings.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Gregg Wonderly <gr...@wonderly.org>.
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 <de...@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!
>>>
>>>
>>
>>
>
>
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 <de...@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!
>>
>>
>
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Gregg Wonderly <gr...@wonderly.org>.
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
>> 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 <de...@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!
>
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Peter Firmstone <ji...@zeus.net.au>.
Is it possible to do this, so that:
a) Clients don't need manual configuration and
b) We don't introduce dependencies on JNI in the platform?
If so, any ideas how? (I'm not being critical, just picking your brains ;)
Peter.
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.
>
>> 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 <de...@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!
>
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Craig L Russell <cr...@oracle.com>.
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.
> 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 <de...@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!
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Gregg Wonderly <gr...@gmail.com>.
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. Associated permissions need to be granted of course.
Gregg Wonderly
Sent from my iPad
On May 13, 2010, at 9:59 AM, Dennis Reedy <de...@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
>
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Dennis Reedy <de...@gmail.com>.
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
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 thinking about providing a ServiceInterface-dl.jar for any new
Platform Services in River, providing class files for backward
compatibility, ensuring existing Jini clients can utilise them too.
I'm not familiar with Window's either, anyone here with some Window's
experience?
Cheers,
Peter.
Gregg Wonderly wrote:
> Peter Firmstone wrote:
>> Anyone got any ideas for PAM in Apache River?
>
> Currently, because JAAS is broken and providing no access to
> authentication APIs of the host OS, we'd have to provide JNI code to
> do authentication against PAM or other native authentication
> mechanisms, if done in the same JVM where less trust paranoia has to
> occur. An external authentication service could be written which
> might bind to "localhost:xxx" and use an SSL cert based authentication
> to connect. We could then use local native processes as
> authentication agents to authenticate Jini users.
>
> My http://pastion.dev.java.net project includes a JNI based
> authentication API that uses PAM on linux. There is/was a difference
> in APIs for Solaris vs Linux that might still need some
> customizations. I am not familiar with what we'd need to use a
> windows based directory service.
>
> Gregg Wonderly
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Gregg Wonderly <gr...@gmail.com>.
We can make use of it. The last update in 2007 may indicate stable code, but may also indicate problematic, dead code. What I have is pretty much JPAM. I recall trying JPAM but chose to create my own, and I do not recall why.
Gregg
Sent from my iPad
On May 12, 2010, at 7:54 PM, Dennis Reedy <de...@gmail.com> wrote:
> I wonder if the JPam work might also fit here? http://jpam.sourceforge.net/
>
>
> On May 12, 2010, at 431PM, Gregg Wonderly wrote:
>
>> Peter Firmstone wrote:
>>> Anyone got any ideas for PAM in Apache River?
>>
>> Currently, because JAAS is broken and providing no access to authentication APIs of the host OS, we'd have to provide JNI code to do authentication against PAM or other native authentication mechanisms, if done in the same JVM where less trust paranoia has to occur. An external authentication service could be written which might bind to "localhost:xxx" and use an SSL cert based authentication to connect. We could then use local native processes as authentication agents to authenticate Jini users.
>>
>> My http://pastion.dev.java.net project includes a JNI based authentication API that uses PAM on linux. There is/was a difference in APIs for Solaris vs Linux that might still need some customizations. I am not familiar with what we'd need to use a windows based directory service.
>>
>> Gregg Wonderly
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Peter Firmstone <ji...@zeus.net.au>.
At 100kb, jpam could fit into a proxy and solve the cross platform
issues on unix / POSIX at least, combined with Gregg's work.
I'd be inclined to choose the direct public API (as an unexposed part of
a proxy implementation) so the implementation can be downloaded without
manual intervention or installation like an SPI requires.
Cheers,
Peter.
Dennis Reedy wrote:
> I wonder if the JPam work might also fit here? http://jpam.sourceforge.net/
>
>
> On May 12, 2010, at 431PM, Gregg Wonderly wrote:
>
>
>> Peter Firmstone wrote:
>>
>>> Anyone got any ideas for PAM in Apache River?
>>>
>> Currently, because JAAS is broken and providing no access to authentication APIs of the host OS, we'd have to provide JNI code to do authentication against PAM or other native authentication mechanisms, if done in the same JVM where less trust paranoia has to occur. An external authentication service could be written which might bind to "localhost:xxx" and use an SSL cert based authentication to connect. We could then use local native processes as authentication agents to authenticate Jini users.
>>
>> My http://pastion.dev.java.net project includes a JNI based authentication API that uses PAM on linux. There is/was a difference in APIs for Solaris vs Linux that might still need some customizations. I am not familiar with what we'd need to use a windows based directory service.
>>
>> Gregg Wonderly
>>
>
>
>
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Dennis Reedy <de...@gmail.com>.
I wonder if the JPam work might also fit here? http://jpam.sourceforge.net/
On May 12, 2010, at 431PM, Gregg Wonderly wrote:
> Peter Firmstone wrote:
>> Anyone got any ideas for PAM in Apache River?
>
> Currently, because JAAS is broken and providing no access to authentication APIs of the host OS, we'd have to provide JNI code to do authentication against PAM or other native authentication mechanisms, if done in the same JVM where less trust paranoia has to occur. An external authentication service could be written which might bind to "localhost:xxx" and use an SSL cert based authentication to connect. We could then use local native processes as authentication agents to authenticate Jini users.
>
> My http://pastion.dev.java.net project includes a JNI based authentication API that uses PAM on linux. There is/was a difference in APIs for Solaris vs Linux that might still need some customizations. I am not familiar with what we'd need to use a windows based directory service.
>
> Gregg Wonderly
Re: PAM - Pluggable Authentication Modules Any Ideas?
Posted by Gregg Wonderly <gr...@wonderly.org>.
Peter Firmstone wrote:
> Anyone got any ideas for PAM in Apache River?
Currently, because JAAS is broken and providing no access to authentication APIs
of the host OS, we'd have to provide JNI code to do authentication against PAM
or other native authentication mechanisms, if done in the same JVM where less
trust paranoia has to occur. An external authentication service could be
written which might bind to "localhost:xxx" and use an SSL cert based
authentication to connect. We could then use local native processes as
authentication agents to authenticate Jini users.
My http://pastion.dev.java.net project includes a JNI based authentication API
that uses PAM on linux. There is/was a difference in APIs for Solaris vs Linux
that might still need some customizations. I am not familiar with what we'd
need to use a windows based directory service.
Gregg Wonderly