geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy (JIRA)" <>
Subject [jira] Commented: (GERONIMO-409) SQLSecurityRealm/SQLLoginModule needs overhaul
Date Tue, 11 Oct 2005 12:05:06 GMT
    [ ] 

Vamsavardhana Reddy commented on GERONIMO-409:

Generating a new query to be on a per-user basis from the "userSelect" and "groupSelect "queries
need to account for UNIONs, JOINs, subqueries and lot more complex things.  Each of the cases
can be solved separately if not in a common way.  Whenever a new query can be generated on
a per-user basis, the new query can be used for getting the user/group information.

Simpler way would be to introduce two more parameters to the login module, say "userSelectByUser"
and "groupSelectByUser" to provide queries on per-user basis.  I feel that it will be lot
easier for one who writes the "userSelect" query to write the same query on a per-user-basis
simultaneously.  When ever these parameters "...ByUser" are supplied, the login module can
use those.  (This will definitely prevent the case of searching through a million entries
before the login module finds the target.)  Otherwise the login module can try to generate
new queries on per-user basis if it can before proceding to user the userSelect and groupSelect

> SQLSecurityRealm/SQLLoginModule needs overhaul
> ----------------------------------------------
>          Key: GERONIMO-409
>          URL:
>      Project: Geronimo
>         Type: Bug
>   Components: security
>     Versions: 1.0-M2
>     Reporter: Aaron Mulder
>     Priority: Critical
>      Fix For: 1.0

> The SQLSecurityRealm and SQLLoginModule do not scale.  In particular, they load all users
and all groups in the security realm once when the realm is started, and again for every login
request.  Imagine a database of thousands of users/groups.
> There should instead be required SQL queries to load a single password given a username,
and to load a list of groups for a single user given a username.  Then there can be optional
SQL queries to load a list of all users or to load a list of all groups, though we still shouldn't
care who the group members are.
> Also, it appears that the digesting features provided by SQLSecurityRealmPasswordDigested
are never invoked, so that class has no effect.  It seems like the best way to implement digesting
would be to make the basic SQLLoginModule take a digest algorithm argument.  If present, the
SQLLoginModule could instantiate and use a digester on the incoming password (and if not,
not).  Then we don't need any extra class for it, and you could enable digesting simply by
adding a login module configuration option.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message