You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by obrand <ob...@yahoo.com> on 2002/01/17 20:38:58 UTC
Talking about authentication
Hi,
I am new to the list. I have been trying to use the JNDIRealm on our
System Architecture: Solaris 8 + OpenLDAP.
Since moving to a better encryption scheme on Solaris 8 is painful (and
mainly undocumented ;-)), we are using the basic crypt algorytthm.
Now I have seen a few issues with the RealmBase and obviously the JNDIRealm.
First of all the notion of Salt is not present in the RealmBase. Salt is
not tied to Unix Crypt but can be applied to any encryption scheme and
is pretty standard. Secondly, when using a custom digest (or not) the
comparison of password is comparing an Hex value (RealmBase) with the
encrypted value found in the backend datastore (LDAP, DB, ...).
Basically the comparison never works.
I have worked on few workarounds and came to these decisions and
impelmented it:
- It would make sense to add a filtering mechanism (a CredentialFilter
XML attribute in a Realm configuration) on the clear and encrypted
credential, so you have room to do any kind of manipulation on both
entities.
- Add a security package for any custom MessageDigest classes and any
JAAS LoginModules and JAAS Configuration classes (in this case, I have a
MessageDigest for the Unix Crypt and an XML based JAAS configuration).
Could you give me feedbacks on these issues ? Thanks
Olivier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Alternate JMX implementation
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 1/17/02 12:14 PM, "Remy Maucherat" <re...@apache.org> wrote:
> Hi,
>
> Tomcat 4 HEAD can now be built and run using an alternate JMX implementation
> (with a much more open-source friendly license :)): OpenJMX
> (www.open-jmx.org).
>
> Note: OpenJMX 1.0b1 will not work with Tomcat, but a build from OpenJMX CVS
> will
>
> Note 2: The main JMX variable in build.properties has been renamed from
> jmxri.jar to jmx.jar
>
> Remy
Awesome!
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Alternate JMX implementation
Posted by co...@covalent.net.
Excelent !
Costin
On Thu, 17 Jan 2002, Remy Maucherat wrote:
> Hi,
>
> Tomcat 4 HEAD can now be built and run using an alternate JMX implementation
> (with a much more open-source friendly license :)): OpenJMX
> (www.open-jmx.org).
>
> Note: OpenJMX 1.0b1 will not work with Tomcat, but a build from OpenJMX CVS
> will
>
> Note 2: The main JMX variable in build.properties has been renamed from
> jmxri.jar to jmx.jar
>
> Remy
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Alternate JMX implementation
Posted by Remy Maucherat <re...@apache.org>.
Hi,
Tomcat 4 HEAD can now be built and run using an alternate JMX implementation
(with a much more open-source friendly license :)): OpenJMX
(www.open-jmx.org).
Note: OpenJMX 1.0b1 will not work with Tomcat, but a build from OpenJMX CVS
will
Note 2: The main JMX variable in build.properties has been renamed from
jmxri.jar to jmx.jar
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Talking about authentication
Posted by obrand <ob...@yahoo.com>.
Craig R. McClanahan wrote:
>
>On Thu, 17 Jan 2002, obrand wrote:
>
>>Date: Thu, 17 Jan 2002 11:38:58 -0800
>>From: obrand <ob...@yahoo.com>
>>Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
>>To: tomcat <to...@jakarta.apache.org>
>>Subject: Talking about authentication
>>
>>Hi,
>>
>>I am new to the list. I have been trying to use the JNDIRealm on our
>>System Architecture: Solaris 8 + OpenLDAP.
>>Since moving to a better encryption scheme on Solaris 8 is painful (and
>>mainly undocumented ;-)), we are using the basic crypt algorytthm.
>>
>
>Interesting timing ... doing something about the issues you raise just
>came close to the top of my TODO list.
>
Cool. Before reading what I have done to solve the problem, I believe
that a JAAS authentication/authorization is more appropriate (and standard).
I have achieved the same goals: login form based on a serie of multiple
login modules (Base64, Cookie, DB, ..)
>
>>Now I have seen a few issues with the RealmBase and obviously the JNDIRealm.
>>First of all the notion of Salt is not present in the RealmBase. Salt is
>>not tied to Unix Crypt but can be applied to any encryption scheme and
>>is pretty standard. Secondly, when using a custom digest (or not) the
>>comparison of password is comparing an Hex value (RealmBase) with the
>>encrypted value found in the backend datastore (LDAP, DB, ...).
>>Basically the comparison never works.
>>
>>I have worked on few workarounds and came to these decisions and
>>impelmented it:
>>
>>- It would make sense to add a filtering mechanism (a CredentialFilter
>>XML attribute in a Realm configuration) on the clear and encrypted
>>credential, so you have room to do any kind of manipulation on both
>>entities.
>>
>
>I had started thinking about adding a passwordMatch() method that would
>support the sorts of stored passwords often seen in LDAP servers
>(something like "{crypt}xxxxx") that could be used for any underlying
>storage technology. To deal with most servers, it would have to support a
>configurable salt value as well, which could become a property of
>RealmBase. (Of course, the binary comparison needs to work correctly no
>matter what.)
>
>Is this what you had in mind? Or, perhaps a small worker class API for
>password matching that could be plugged in to any Realm without
>subclassing?
>
Ok, so what I have done is:
Created a org.apache.catalina.realm.Filter interface with 2 methods:
- String getClearCredential()
- String getEncodedCredential()
And created an Instance of it called: SaltedFilter
Basically, I am initializing the Filter with a regexp: "(\\{.*\\})?(.*)"
which splits the {<encoded method>} from the returned encoded
credential. The getEncodedCredential then returns the part matching the
second parenthesis.
The getClearCredential calls the getEncodedCredential to extract the 2
first characters (that how Unix works) and prepend it to the clear
credential the user provided.
Finally I have a FilterFactory which role is to cache all the created
filters (so we don't re-initialize every time).
In the server.xml, you add an attribute to the Realm you are using:
CredentialFilterClass. In my case, I am passing the SaltedFilter.
The JNDIRealm then acts upon this attribute:
If it is there, then gethold a the configured Filter using the static
method of the FilterFactory and pass an intialized CredentialInfo
(containing the 2 passwords: clear and the one retrieved from the
datastore).
Then the usual code takes on: Check if a digest has been configured (I
have created a CryptDigest and TomcatProvider) and pass the password
returned by the getClearCredential() to it.
It looks a little complex and was not the first thing I did, but after
refactoring, it made more sense. I did not want to put the logic of
crypt, salt, extraction of {crypt|CRYPT|MD5, ....} in the server.xml.
>
>>- Add a security package for any custom MessageDigest classes and any
>>JAAS LoginModules and JAAS Configuration classes (in this case, I have a
>>MessageDigest for the Unix Crypt and an XML based JAAS configuration).
>>
>
>That would be very useful. There's a basic JAASRealm implementation in
>the head branch, but it is not done yet and could use these features.
>
I have to refactor (rewrite) the code since I wrote it for my previous
job.... I also wrote a full blown JAAS implementation that can run on
Java 1.2.
but in order to use it, I need to do the same: refactor it. It might be
a good idea if a separate Jakarta project is created, like Security or JAAS.
This kind of project makes sense across all projects. And it will be
cool to have people dropping LoginModules !!
>
>I'd also like to talk about a JAAS-related topic that has been puzzling me
>-- when you get a Subject back, how do you identify which Principal object
>represents the user (so you can return it for request.getUserPrincipal()
>calls), and which ones represent roles? The best I can think of at the
>moment is to be able to configure a set of classnames that your JAAS
>implementation returns, and use instanceof checks to tell -- but that
>seems like a kludge.
>
Yes it sounds like a bad kludge ;-)
My JAAS implementation does not cover Authorization but only
Authentication. Basically, you are right. There is no specification on how
to organize Principals beside the public and private information. I
think that Roles are totally different but not sure since I have not
really looked at it.
>
>
>>Could you give me feedbacks on these issues ? Thanks
>>
>>
>>Olivier
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Re: Talking about authentication
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 17 Jan 2002, obrand wrote:
> Date: Thu, 17 Jan 2002 11:38:58 -0800
> From: obrand <ob...@yahoo.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: tomcat <to...@jakarta.apache.org>
> Subject: Talking about authentication
>
> Hi,
>
> I am new to the list. I have been trying to use the JNDIRealm on our
> System Architecture: Solaris 8 + OpenLDAP.
> Since moving to a better encryption scheme on Solaris 8 is painful (and
> mainly undocumented ;-)), we are using the basic crypt algorytthm.
>
Interesting timing ... doing something about the issues you raise just
came close to the top of my TODO list.
> Now I have seen a few issues with the RealmBase and obviously the JNDIRealm.
> First of all the notion of Salt is not present in the RealmBase. Salt is
> not tied to Unix Crypt but can be applied to any encryption scheme and
> is pretty standard. Secondly, when using a custom digest (or not) the
> comparison of password is comparing an Hex value (RealmBase) with the
> encrypted value found in the backend datastore (LDAP, DB, ...).
> Basically the comparison never works.
>
> I have worked on few workarounds and came to these decisions and
> impelmented it:
>
> - It would make sense to add a filtering mechanism (a CredentialFilter
> XML attribute in a Realm configuration) on the clear and encrypted
> credential, so you have room to do any kind of manipulation on both
> entities.
I had started thinking about adding a passwordMatch() method that would
support the sorts of stored passwords often seen in LDAP servers
(something like "{crypt}xxxxx") that could be used for any underlying
storage technology. To deal with most servers, it would have to support a
configurable salt value as well, which could become a property of
RealmBase. (Of course, the binary comparison needs to work correctly no
matter what.)
Is this what you had in mind? Or, perhaps a small worker class API for
password matching that could be plugged in to any Realm without
subclassing?
> - Add a security package for any custom MessageDigest classes and any
> JAAS LoginModules and JAAS Configuration classes (in this case, I have a
> MessageDigest for the Unix Crypt and an XML based JAAS configuration).
>
That would be very useful. There's a basic JAASRealm implementation in
the head branch, but it is not done yet and could use these features.
I'd also like to talk about a JAAS-related topic that has been puzzling me
-- when you get a Subject back, how do you identify which Principal object
represents the user (so you can return it for request.getUserPrincipal()
calls), and which ones represent roles? The best I can think of at the
moment is to be able to configure a set of classnames that your JAAS
implementation returns, and use instanceof checks to tell -- but that
seems like a kludge.
> Could you give me feedbacks on these issues ? Thanks
>
>
> Olivier
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>