Craig R. McClanahan wrote:
>
>On Thu, 17 Jan 2002, obrand wrote:
>
>>Date: Thu, 17 Jan 2002 11:38:58 -0800
>>From: obrand <[EMAIL PROTECTED]>
>>Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
>>To: tomcat <[EMAIL PROTECTED]>
>>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: <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
