You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alan Chaney <al...@compulsivecreative.com> on 2009/02/21 21:54:34 UTC
Authenticating Users
Hi
We have a site which has users log in to create/edit account
information. Nothing unusual there. Currently this is implemented with a
JDBCRealm and it all works OK.
However, we have a 'marketing requirement' to remove case sensitivity
(but NOT case preservation) from user names and passwords. I cannot see
anyway to do this directly with JDBCRealm or DataSourceRealm. Unless I'm
missing something, the username and password provided to j_securitycheck
are explicitly matched for case.
Additionally, we will shortly need to offer an alternative login
mechanism - using either a login name or an email address in the same field.
So far, I can see the following options:
1. Implement a filter that 'sits around' the login form and translates
case on password and username to lower case and create a lowercase
'shadow' password table in my database. So, when a request is received
for the 'secured' pages this would be fed through this filter. However,
I don't think this will work, because I suspect that the security check
is run BEFORE any filters that I have configured in web.xml.
2. Implement some java script to convert entered fields to lower case on
the login form (GHASTLY!) Still doesn't fix the password thing.
3. Implement my own Realm - intercept the requests - identify the
supplied string in the username field as an email address (or not), look
up the user by email address in the database (which in my case must be
unique). As I use PostgreSQL I can then write a 'like' query to case
insensitively find matching user and password. Upside - it should work.
Downside - I then have to add the resulting jar to $TOMCAT_HOME/lib on
all my servers and update the MBean descriptor (which I don't completely
understand how to do - advice?)
4. Possibly do something similar to 3 but with a JAAS.
Does anyone have any suggestions or comments? I'm perfectly OK with
using Acegi - my only issue with that after a browse through the docs I
don't see how I can meet my requirement of username/email and password
case insensitive but case preserving without additional code for Acegi
either. Obviously I can take that issue to the acegi/spring forums if
acegi is the only solution (that is 1, 3, and 4. above won't work - 2.
is out)
Thanks in advance
Alan Chaney
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Alan Chaney <al...@compulsivecreative.com>.
Mark Thomas wrote:
>
> 5. Patch DataSourceRealm (should just be a couple of changes to make the
> checks case insensitive) and deploy your patched version to each of your
> Tomcat instances. To do this you'd put your DataSourceRealm.class file
> in CATALINA_HOME/lib/org/apache/catalina/realm
>
> 6. Make case sensitivity configurable and contribute your patch back to
> the ASF. Providing it is database neutral, there is a good chance it
> will be accepted for Tomcat 7 and maybe back-ported to Tomcat 6.
>
> Mark
Ok Mark I'll have a go at 5. and 6. I'll report back in a few days.
Regards
Alan Chaney
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Robert Koberg <ro...@koberg.com>.
(function() {
var doLogin = function() {
var uname = doc.byId("name").toLowerCase();
var passw = doc.byId("password").toLowerCase();
//var digest = sha1.digest(uname + ":My Realm:" + passw);
xhr.send(...);
}
return {
login: function() {
doLogin();
return false;
}
}
})();
...
<input type="submit" onclick="login()"/>
all hidden and private handling of the user name and password. Might
not work without javascript :)
On Feb 22, 2009, at 4:11 PM, Gregor Schneider wrote:
> To the OP:
>
> 1. May I ask what database it is you're using?
>
> 2- I'd go for the following solution:
>
> Create a JSP-page accepting the credentials. The username should be
> converted to uppercase. The password should be left as is so that
> case-sensivity here is maintained.
>
> Don't know if I'm missing something, but to me that looks like a walk
> in the park.
>
> Rgds
>
> Gregor
> --
> just because your paranoid, doesn't mean they're not after you...
> gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
> gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Authenticating Users
Posted by "Propes, Barry L " <ba...@citi.com>.
This is what I did for our JDBC realm....forced uppercase with javascript on the alphan-numeric user id.
Then the password was whatever they made it, even though it was case sensitive.
Trying to figure out what the good of making passwords case-insensitive would be. Purpose-defeating at best it seems.
-----Original Message-----
From: Gregor Schneider [mailto:rc46fi@googlemail.com]
Sent: Sunday, February 22, 2009 3:12 PM
To: Tomcat Users List
Subject: Re: Authenticating Users
To the OP:
1. May I ask what database it is you're using?
2- I'd go for the following solution:
Create a JSP-page accepting the credentials. The username should be converted to uppercase. The password should be left as is so that case-sensivity here is maintained.
Don't know if I'm missing something, but to me that looks like a walk in the park.
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin,
Wow.
On 2/22/2009 8:52 PM, Martin Gainty wrote:
>> Alan Chaney wrote:
>>
>> To summarize
>>
>> 1. password be case insensitive [I may be able to talk them out of this]
> MG>handled from java.lang.String toUpperCase/toUpperCase
> http://java.sun.com/javase/6/docs/api/java/lang/String.html
He's trying to do a case-insensitive match in the database. Do you
suggest executing "SELECT * FROM user" and then uppercasing every
username looking for the right one? It's already been pointed out that
many databases already perform case-insensitive CHAR/VARCHAR matching
/and/ that not all databases have the same functions for performing this
on the server-side (which is the only reasonable place to do it).
>> 2. username be case insensitive.
> MG>leave as case-sensitive
What's the matter... you don't like the requirements?
>> 3. email address can be used as a synonym for the user name.
> MG>store email as a column in your users table
Er... he's already got that. Have you been reading?
>> 4. Security managed by Tomcat CMS.
> MG>use Realm as earlier suggested storing user and role info in users and user_roles tables
> MG>respectively
He's already doing that.
>> Mark T suggested that I modify DSR appropriately.
> MG>DSR is ready for deployment just match your tablenames for users and user_roles
> MG>also match your userNameCol and userCredCol and roleNameCol
Not true... he wants to use /either/ username /or/ email address as the
user identifier.
>> Chris Schultz pointed out correctly that it gets a bit more complicated
>> if the pwd must be hashed.
> MG>no harm stick into Oracle DB as a Blob column (binary large object) or as RAW
Why would you bother doing that? The digester already provides the
hashed password as a string, so putting it into a CHAR field makes more
sense.
>> I've looked at the code to DSR and it seems to me that the following
>> would work.
>>
>> 1. add an 'alternative' userNameCol (eg altNameCol) and in the
>> configuration as above point that at the email column.
> MG>good..
>
>> 2. in the code, IF the login fails using the 'user_name' then try it
>> with the altNameCol.
> MG>the result from action class will path you there ..but you're on the right track..
Huh?
>> Defaults could be chosen such that the current configuration setup still
>> works (eg the default value for isCaseInsensitive is false)
> MG>sensitive stuff like username/password goes in DB
> MG>everything else to get the page up and running can go into a flat file(.properties/stylesheets)
Okay, my brain is hurting. What are you talking about?
>> Only real gotcha that I can see for making it database independent is
>> that the function used to create lower case is not univerally 'lower()'
>> (M/SQL appears to be toLower()) so it might be necessary to pass the
>> string for the function name as an optional configuration parameter.
> MG>I've been working with Oracle recently MySQL last year and Oracle is case-sensitive
> MG>oracle!=ORACLE but MySQL will take upper/lower or camelcase queriesfor same result
If you mean that MySQL performs CHAR and VARCHAR comparisons without
regard to case then yes, this is true. You can get case-sensitive
matches by casting one of the operands to BINARY CHAR/VARCHAR.
>> I realize that many people would advise against the idea of case
>> insensitive passwords - however, despite my personal reservations I am
>> willing to accept that in the case of this particular application the
>> reduction in security is acceptable.
> MG>decide on uppercase or lowercase and stick to it..
>
>> If hashed pwds are used then there are 3 solutions:
>>
>> 1. don't allow case insensitive passwords - only user names.
> MG>UserNames should be case sensitive AL != al (at least in Oracle)
Dude. Read. The. Requirements. Nobody cares how you think things should
be. This is a business requirement. You can't simply say "no".
>> 2. provide two columns one for lower case versions of the pwd.
> MG>not a good idea and violates data normalisation one copy in DB
> MG>use uppercase or lower case only for view
Two different passwords in the database is not denormalization.
Whenever we change password strategies (it's happened twice), we store
the old-style password in one column and the new-style password in
another. After a while (usually like a year or more), we phase-out the
old-style and suspend the logins of all the users who haven't "upgraded"
their passwords. I think this is a perfectly reasonable strategy.
>> 3. convert all the existing password HASHES to the lower case equivalent,
> MG>wont work A (0x41) != a(0x61) ..you can assume tolower is a simple addition of hex 20
> MG>when the hash algo gets ahold of the character the 0x41 hashes differently than 0x61
This is a bad assumption as it only works with US-ASCII. This is not
even true for the simple Latin charsets that are included in ISO-8859-1.
He's talking about using a lowercase version of all passwords to
generate hashes. These new-style hashes will be stored in the new-style
column in the dat...
Oh, forget it. We all know what's going on.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmiEsoACgkQ9CaO5/Lv0PCfbQCeJ2A0NU5uD4Zh0nzFUs94u1yA
XzwAoKXxzjo3aPCv6UWKZXgFlON8HApX
=Lv3s
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Authenticating Users
Posted by Martin Gainty <mg...@hotmail.com>.
>
> Martin Gainty wrote:
> > Which specific attributes are you seeking that are not in DataSourceRealm?
> > <Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
> > dataSourceName="jdbc/authority"
> > userTable="users" userNameCol="user_name" userCredCol="user_pass"
> > userRoleTable="user_roles" roleNameCol="role_name"/>
> > http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm
> >
> > ?
> >
> To summarize
>
> I (or,actually my "marketing dept') have the following requirements.
MG>yes I keep forgeting they're running the show these days
> 1. password be case insensitive [I may be able to talk them out of this]
MG>handled from java.lang.String toUpperCase/toUpperCase
http://java.sun.com/javase/6/docs/api/java/lang/String.html
> 2. username be case insensitive.
MG>leave as case-sensitive
> 3. email address can be used as a synonym for the user name.
MG>store email as a column in your users table
> 4. Security managed by Tomcat CMS.
MG>use Realm as earlier suggested storing user and role info in users and user_roles tables MG>respectively
>
> Mark T suggested that I modify DSR appropriately.
MG>DSR is ready for deployment just match your tablenames for users and user_roles
MG>also match your userNameCol and userCredCol and roleNameCol
> Chris Schultz pointed out correctly that it gets a bit more complicated
> if the pwd must be hashed.
MG>no harm stick into Oracle DB as a Blob column (binary large object) or as RAW
>
> I've looked at the code to DSR and it seems to me that the following
> would work.
>
> 1. add an 'alternative' userNameCol (eg altNameCol) and in the
> configuration as above point that at the email column.
MG>good..
> 2. in the code, IF the login fails using the 'user_name' then try it
> with the altNameCol.
MG>the result from action class will path you there ..but you're on the right track..
> 3. to make things case insenstive simply convert the username to lower
> case and use a 'lower' function on the column value.
MG>store all strings as either uppercase or all lowercase your app may not be case-sensitive
MG>but Databases are case-sensitive
> 4. to make the thing a bit more flexible an additional boolean parameter
> 'isCaseInsensitive' could be added to select the behavior has in 3. above.
MG>make sure its case sensitive by the time it goes into the DB
> Defaults could be chosen such that the current configuration setup still
> works (eg the default value for isCaseInsensitive is false)
MG>sensitive stuff like username/password goes in DB
MG>everything else to get the page up and running can go into a flat file(.properties/stylesheets)
> Only real gotcha that I can see for making it database independent is
> that the function used to create lower case is not univerally 'lower()'
> (M/SQL appears to be toLower()) so it might be necessary to pass the
> string for the function name as an optional configuration parameter.
MG>I've been working with Oracle recently MySQL last year and Oracle is case-sensitive
MG>oracle!=ORACLE but MySQL will take upper/lower or camelcase queriesfor same result
> I realize that many people would advise against the idea of case
> insensitive passwords - however, despite my personal reservations I am
> willing to accept that in the case of this particular application the
> reduction in security is acceptable.
MG>decide on uppercase or lowercase and stick to it..
> If hashed pwds are used then there are 3 solutions:
>
> 1. don't allow case insensitive passwords - only user names.
MG>UserNames should be case sensitive AL != al (at least in Oracle)
> 2. provide two columns one for lower case versions of the pwd.
MG>not a good idea and violates data normalisation one copy in DB
MG>use uppercase or lower case only for view
> 3. convert all the existing password HASHES to the lower case equivalent,
MG>wont work A (0x41) != a(0x61) ..you can assume tolower is a simple addition of hex 20
MG>when the hash algo gets ahold of the character the 0x41 hashes differently than 0x61
> but hashed passwords are not my principal concern
>
> I've downloaded and built 6.0.18 and looked at the DSR code - doesn't
> look like a very big job to make the changes that I want so I may have
> go tomorrow. As I use 6.0.18 I can easily test it by just patching in
> the .class file for DataSourceRealm on my dev. system.
MG>yes the DSR example is comprehensive and easy to follow
MG>Keep us apprised on how you progress..
MG>Best
> Regards
MG>MG
> Alan
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
It’s the same Hotmail®. If by “same” you mean up to 70% faster.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Same_022009
Re: Authenticating Users
Posted by Alan Chaney <al...@compulsivecreative.com>.
Martin Gainty wrote:
> Which specific attributes are you seeking that are not in DataSourceRealm?
> <Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
> dataSourceName="jdbc/authority"
> userTable="users" userNameCol="user_name" userCredCol="user_pass"
> userRoleTable="user_roles" roleNameCol="role_name"/>
> http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm
>
> ?
>
To summarize
I (or,actually my "marketing dept') have the following requirements.
1. password be case insensitive [I may be able to talk them out of this]
2. username be case insensitive.
3. email address can be used as a synonym for the user name.
4. Security managed by Tomcat CMS.
Mark T suggested that I modify DSR appropriately.
Chris Schultz pointed out correctly that it gets a bit more complicated
if the pwd must be hashed.
I've looked at the code to DSR and it seems to me that the following
would work.
1. add an 'alternative' userNameCol (eg altNameCol) and in the
configuration as above point that at the email column.
2. in the code, IF the login fails using the 'user_name' then try it
with the altNameCol.
3. to make things case insenstive simply convert the username to lower
case and use a 'lower' function on the column value.
4. to make the thing a bit more flexible an additional boolean parameter
'isCaseInsensitive' could be added to select the behavior has in 3. above.
Defaults could be chosen such that the current configuration setup still
works (eg the default value for isCaseInsensitive is false)
Only real gotcha that I can see for making it database independent is
that the function used to create lower case is not univerally 'lower()'
(M/SQL appears to be toLower()) so it might be necessary to pass the
string for the function name as an optional configuration parameter.
I realize that many people would advise against the idea of case
insensitive passwords - however, despite my personal reservations I am
willing to accept that in the case of this particular application the
reduction in security is acceptable.
If hashed pwds are used then there are 3 solutions:
1. don't allow case insensitive passwords - only user names.
2. provide two columns one for lower case versions of the pwd.
3. convert all the existing password HASHES to the lower case equivalent,
but hashed passwords are not my principal concern
I've downloaded and built 6.0.18 and looked at the DSR code - doesn't
look like a very big job to make the changes that I want so I may have
go tomorrow. As I use 6.0.18 I can easily test it by just patching in
the .class file for DataSourceRealm on my dev. system.
Regards
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Authenticating Users
Posted by Martin Gainty <mg...@hotmail.com>.
Which specific attributes are you seeking that are not in DataSourceRealm?
<Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
dataSourceName="jdbc/authority"
userTable="users" userNameCol="user_name" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name"/>
http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm
?
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> Date: Sun, 22 Feb 2009 13:47:54 -0800
> From: alan@compulsivecreative.com
> To: users@tomcat.apache.org
> Subject: Re: Authenticating Users
>
> Gregor Schneider wrote:
> > To the OP:
> >
> > 1. May I ask what database it is you're using?
> >
> Postgres - but a more general solution would be nice.
> > 2- I'd go for the following solution:
> >
> > Create a JSP-page accepting the credentials. The username should be
> > converted to uppercase. The password should be left as is so that
> > case-sensivity here is maintained.
> >
>
> That doesn't actually fit in with the Servlet CMS. I can easily decode
> the user name and password by your mechanism. However, then I have to
> rather extensively modify my code (covering 3 applications and 4 web
> services) to apply the credentials. What I was looking for was a way of
> extending what I already have.
>
> > Don't know if I'm missing something, but to me that looks like a walk
> > in the park.
> >
> See above. The problem is not decoding the password, but making sure
> that the container managed security mechanism is maintained.
>
> So far, the best suggestions that I've had are:
>
> 1. Modify DataSourceRealm
> 2. Use secuirityfilter.
>
> From my point of view, as I don't use hashed passwords at the moment
> the easiest thing to do is to modify the DataSourceRealm as suggested by
> Mark Thomas. However, I think that the ability to extend the login
> system to use either a user name or an email address would probably be
> useful for other people. I'll give it some thought.
>
> Regards
>
> Alan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > Rgds
> >
> > Gregor
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
Windows Live™ Hotmail®…more than just e-mail.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009
Re: Authenticating Users
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan,
On 2/22/2009 4:47 PM, Alan Chaney wrote:
> From my point of view, as I don't use hashed passwords at the moment the
> easiest thing to do is to modify the DataSourceRealm as suggested by
> Mark Thomas. However, I think that the ability to extend the login
> system to use either a user name or an email address would probably be
> useful for other people.
I think it might be easier than you think.
Here's the code for DataSourceRealm's SQL query builder for the
"credential selection" (TC 6.0.16):
// Create the credentials PreparedStatement string
temp = new StringBuffer("SELECT ");
temp.append(userCredCol);
temp.append(" FROM ");
temp.append(userTable);
temp.append(" WHERE ");
temp.append(userNameCol);
temp.append(" = ?");
preparedCredentials = temp.toString();
All you need to do is hack the start() method (which builds the SQL
queries) plus the credentials() method and you should be good to go. You
could create a relatively inelegant system of <Realm> attributes that
would build a more complex query, or you could just hack the realm and
be done with it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmh/0gACgkQ9CaO5/Lv0PAYVQCgvDo9FpFQd4zxgmuG66zqNe1y
MlUAn3MmLx8Bb4LScyhXPpfIspcCKygu
=8PUl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Alan Chaney <al...@compulsivecreative.com>.
Gregor Schneider wrote:
> To the OP:
>
> 1. May I ask what database it is you're using?
>
Postgres - but a more general solution would be nice.
> 2- I'd go for the following solution:
>
> Create a JSP-page accepting the credentials. The username should be
> converted to uppercase. The password should be left as is so that
> case-sensivity here is maintained.
>
That doesn't actually fit in with the Servlet CMS. I can easily decode
the user name and password by your mechanism. However, then I have to
rather extensively modify my code (covering 3 applications and 4 web
services) to apply the credentials. What I was looking for was a way of
extending what I already have.
> Don't know if I'm missing something, but to me that looks like a walk
> in the park.
>
See above. The problem is not decoding the password, but making sure
that the container managed security mechanism is maintained.
So far, the best suggestions that I've had are:
1. Modify DataSourceRealm
2. Use secuirityfilter.
From my point of view, as I don't use hashed passwords at the moment
the easiest thing to do is to modify the DataSourceRealm as suggested by
Mark Thomas. However, I think that the ability to extend the login
system to use either a user name or an email address would probably be
useful for other people. I'll give it some thought.
Regards
Alan
> Rgds
>
> Gregor
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Gregor Schneider <rc...@googlemail.com>.
To the OP:
1. May I ask what database it is you're using?
2- I'd go for the following solution:
Create a JSP-page accepting the credentials. The username should be
converted to uppercase. The password should be left as is so that
case-sensivity here is maintained.
Don't know if I'm missing something, but to me that looks like a walk
in the park.
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Alan Chaney <al...@compulsivecreative.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark,
>
I was the OP on this one. Mark just made a couple of suggestions.
> On 2/21/2009 4:06 PM, Mark Thomas wrote:
>
>> 5. Patch DataSourceRealm
>>
>> 6. Make case sensitivity configurable and contribute your patch back to
>> the ASF.
>>
>
> 7. Use securityfilter to write your realm, and not be tied to Tomcat.
>
Had a brief look at 'securityfilter' - however we actually do require
container managed security as we have several applications. Other
alternative as previously mentioined is acegi.
> 8. Many databases use case-insensitive string comparisons already.
> Case-insensitive passwords (probably a bad idea!)
Actually, in general, I agree that its a bad idea. However, each case
has to be handled in the light of the actual users expectations.
In the case of this specific application the users are artists who are
generally extremely computer naive. We commonly get support enquiries
"I can't log into my account" EVEN THOUGH we have sent them their
account names and passwords because they are not correctly capitalizing
their usernames or passwords.
It is important to keep to keep the case of usernames because, as I
said, they are artists, and the capitalization may have significance to
them as part of their brand.
The information on the site is publically available after it has been
published. There is no commercial or sensitive information on the site.
> will work if you
> aren't hashing them. If you are, you'll have to lowercase them or something.
>
>
Exactly. One problem for a general solution is that there are variations
in the name of the 'lowercase' function between databases. So far, I've
found that Postgres, MySQL and Oracle appear to support 'lower()' but
M/SQL has it as tolower() (thanks again MS)
> If you /are/ hashing them, you'll need to do a password migration where
> anyone who changes their password gets it lowercased but passwords that
> existed beforehand are still case-sensitive. You cannot avoid this, now
> matter what your solution is.
>
In this specific case at the moment we aren't hashing them, but you
raise a good general point about hashing which I'll have to think about.
Regards
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 2/21/2009 4:06 PM, Mark Thomas wrote:
> 5. Patch DataSourceRealm
>
> 6. Make case sensitivity configurable and contribute your patch back to
> the ASF.
7. Use securityfilter to write your realm, and not be tied to Tomcat.
8. Many databases use case-insensitive string comparisons already.
Case-insensitive passwords (probably a bad idea!) will work if you
aren't hashing them. If you are, you'll have to lowercase them or something.
If you /are/ hashing them, you'll need to do a password migration where
anyone who changes their password gets it lowercased but passwords that
existed beforehand are still case-sensitive. You cannot avoid this, now
matter what your solution is.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmhZ48ACgkQ9CaO5/Lv0PAlOACgrwTelHoTXc0nAbo0+D0rFhez
G3YAnjh3JqHj/bLWvFY2vsFFRMTcd7oK
=GYQE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authenticating Users
Posted by Mark Thomas <ma...@apache.org>.
Alan Chaney wrote:
> We have a site which has users log in to create/edit account
> information. Nothing unusual there. Currently this is implemented with a
> JDBCRealm and it all works OK.
I'd base your solution on the DataSourceRealm. JDBCRealm is very heavily
synchronised .
> So far, I can see the following options:
>
> 1. Implement a filter that ...
>
> 2. Implement some java script ...
>
> 3. Implement my own Realm ...
>
> 4. Possibly do something similar to 3 but with a JAAS.
5. Patch DataSourceRealm (should just be a couple of changes to make the
checks case insensitive) and deploy your patched version to each of your
Tomcat instances. To do this you'd put your DataSourceRealm.class file
in CATALINA_HOME/lib/org/apache/catalina/realm
6. Make case sensitivity configurable and contribute your patch back to
the ASF. Providing it is database neutral, there is a good chance it
will be accepted for Tomcat 7 and maybe back-ported to Tomcat 6.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org