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.
> 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: <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]>
