On 10 Oct 00, at 18:27, Oleg Nitz wrote:
Hi Oleg,
You make some good points. I certainly think you will be able to
implement the system you describe using JAAS in this way. I hope
you won't mind if I respond again, because even though you make
good points, I think there are still a few issues you might want to
consider.
(Please remember that I am not an expert in security, so you
should weigh my advice accordingly. I started picking at this sub-
project only because no one else seemed to want to start it, not
because I know the right way.)
>
> 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.
I think any security scheme that performs well will need some sort
of caching, so I think this is the right approach in general. :-)
One thing you might want to think about: if the client isn't trusted, I
don't think you can just look them up in the security pool. I think
you need to reauthenticate non-trusted clients with each remote
call.
Imagine some "very bad person" logs on with the right user name
but the wrong password. If the real user has logged on recently,
and so the user name happens to be in the security pool, you won't
reauthenticate. As a result, you never discover this incorrect
password and the bad guy has access. Caching of authentication
information only works with a trusted client. You can cache role
information with abandon, if you can distinguish (e.g. if trusted
allow access; else authenticate through JAAS module 1; if roles in
security pool use them; else obtain them through JAAS module 2).
>
> 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.
Fair enough. It sounds at first glance that you could use JAAS, but
I'm still not convinced of the advantages. (You mention a few--e.g.
not GPL--at the end of this e-mail, that I discuss a little.)
>
> 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.
If you can cache the JAAS information, this will be less of a
concern of course. The ability to do this may or may not depend on
having a trusted client, as I mentioned above. But we wanted to
implement trusted-client functionality anyway. :-)
> 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?
I don't know all of the details of JAAS, and don't know exactly how
you would configure it to respond on a per-container basis. But for
a standard authentication, the login context performs the
authentication in two phases. In the first, the context instructs
configured login modules to perform authentication only. If all
configured modules succeed, each module is instructed to
"commit" the authentication. It is here that the module associates
to the subject the corresponding principals and credentials. So I
perceived the additional overhead as (1) stemming from the two-
phase commit (and the callback architecture); (2) coming from the
additional overhead of a subject (rather than principal) based
scheme; and POSSIBLY (3) Java security related overhead (e.g.
doPrivileged() or access checks). Also, there may be additional
overhead in specifying the correct login modules on a per-container
basis. Frankly, I don't know how to do this off the top of my head
(shows you how little I know about all of this), so I'm not sure what
your plan was here.
>
> 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?)...
(Just as an aside. The caching piece should be a standard part of
the jBoss distribution. There should be a CacheRealmManager that
front-ends other RealmManagers, & the same for the
EJBSecurityManager. The typical user will not implement this, or
actually do any security-related programming whatsoever.)
> 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.
Would you be able to use the "database" EJBSecurityManager and
RealmMapping implementation classes that I prototyped if you
could specify the database structure in a configuration file? (That
was my intent.) For the most part, I would like jBoss code to work
with proprietary database and application structures as-is. :-)
(The typical user shouldn't have to write security code just because
he or she stores his user-names and passwords in a table with a
funky name.)
> Whereas JAAS interfaces can be used without GPL inconveniences.
>
It's a fine line. We would like a nifty general-purpose LDAP
EJBSecurityManager (or, e.g., a caching front-end) to be donated
to the community. But we don't care as much about code specific
to a proprietary setup.
I'm not a GPL fanatic. If there is a real problem--and pending the
approval of the jBoss board of directors--I'll rerelease the two
interfaces under something less restrictive than the GPL. I don't
think it's a big deal in this case.
If there's a good reason to go with JAAS for user-role mapping, I'm
all for it. Believe me, I'm not attached to the current code or design.
But if the issue is primarily GPL, it seems a bit of extra work for
what we might really find to be a non-issue if we can work through
the details.
Anyway, like I said, I think you could probably make your design
work (assuming you can indicate to JAAS which modules to use).
It will be interesting to see how it goes.
-Dan
> Best regards,
> Oleg
>
>
>
