Hi Dan,
Dan OConnor wrote:
DO> Adding this method to RealmMapping for principal mapping sounds
DO> like a great idea: +1. One small suggestion for you to consider
DO> before we actually put it in: maybe the method signature could be:
DO> Principal getPrincipal( Principal user )
+1.
DO> Assume a client calls a stateless session bean facade (bean A)
DO> which calls a service layer component (bean B) which iterates
DO> through 20 entities (bean C1-C20). I think that the JAAS module
DO> will need to be called once for A, once for B, and twenty times for
DO> C, right?
You forget about the security pool that would contain realm
mapping information, e.g. a HashMap with keys (bean name, user name)
and values (principal, roles).
The algorithm of authorization of a user call would be the following:
if the client is trusted, then allow access;
else lookup in the security pool,
if found, obtain a set of roles
else use JAAS module to perform authentication and
obtain the set of Credentials (roles) for authorization
Thus, in your example there will be from zero to three JAAS calls.
DO> In the design that separates authentication from role-mapping, you
DO> would not necessarily need to reauthenticate the principal on each
DO> call, nor would you need to perform any authentication from a
DO> "trusted client." But I think under your design, where JAAS
DO> modules do both (am I understanding this correctly?) you can't
DO> avoid these authentication calls.
JAAS modules on server in my current schema may or may not perform
password verification. What they must do is to provide Credentials for
subsequent authorization, which is a valid task for LoginModules
(if I understand correctly the JAAS specification).
Maybe you are right and password verification should be separated
from role-mapping (two sets of LoginModules on server?),
but I believe that the use of LoginModules for role-mapping that I
propose is a valid use and is in spirit of JAAS.
DO> Finally, I think for principal-to-role mapping, a call to a simple Java
DO> class (cached in the container by the MBean) will have less
DO> overhead than a JAAS call. Does this seem likely to you as well?
First, this overhead will be only on the first access of the given
user to the given bean.
Second, the overhead would be minor: JAAS reads a configuration
file, instantiates a LoginModule and calls login() and commit(),
while in your variant jBoss reads a configuration file,
instantiates a RealMapping and calls doesUserHaveRole().
So where is the overhead? One more method call?
DO> If the JAAS module is also responsible for role mappings, this has
DO> a major consequence that I think should be avoided: third-party
DO> JAAS modules can't be directly plugged into the system, because
DO> they won't provide this role mapping.
Okay, let's separate authentication and role-mapping and use two sets
of LoginModules on server.
DO> In any case, I'm interested in your motivations for using JAAS for
DO> do the principal-to-role mappings. What are the advantages of this
DO> approach?
1) Assume that we have 1000 users and 100 roles and each user has
many roles. All this info is stored in a database.
I am going to implement RealmMapping interface.
I can load all the realm-mapping info to the memory, or
I can perform database query on each call, or
I can have a cache (or pool - which term suits better?),
where I store the pieces of the realm mapping,
which I read from the database on each call.
Of course, I choose the latter approach, and most of jBoss users will
do the same choice. And then I start implementing the cache (pool?)...
Now, if I have to implement LoginModule interface, all I need to do is
to read from the database a piece of the realm mapping for the given
user, all caching/pooling jBoss will do for me.
2) If I have to implement org.jboss.system.RealmMapping interface,
then I have to make my code GPL. Most probably I shall write
a "glue code" (I can hardly imagine a customer who will be glad
to know that all the source code for security modules in his system is
open). Then I'll have to distribute this dummy glue source code
with my commercial application. And even if I put the whole
implementation under GPL, it would be absolutely useless for jBoss
community since my implementation uses our proprietary database and
application structure.
Whereas JAAS interfaces can be used without GPL inconveniences.
Best regards,
Oleg
