tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: Authenticating Users
Date Mon, 23 Feb 2009 01:52:46 GMT

> 
> 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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message