Hi Dan,
Dan OConnor wrote:
DO> Imagine some "very bad person" logs on with the right user name
DO> but the wrong password. If the real user has logged on recently,
DO> and so the user name happens to be in the security pool, you won't
DO> reauthenticate. As a result, you never discover this incorrect
DO> password and the bad guy has access. Caching of authentication
DO> information only works with a trusted client. You can cache role
DO> information with abandon, if you can distinguish (e.g. if trusted
DO> allow access; else authenticate through JAAS module 1; if roles in
DO> security pool use them; else obtain them through JAAS module 2).
We should have a cache not only for realm mapping info, but also for
authenticated pairs "user name -> password" (such pair can be
purged from the cache by timeout).
On method invocation we seek for the user name in the cache, if fould
we merely compare two passwords, which are char arrays,
else we perform authentication.
The realm mapping cache should depend on password cache: the realm
mapping info should be purged only when password info is purged.
Then we wouldn't need to separate JAAS module 1 from JAAS module 2,
they go in the same JAAS configuration file sequentially.
We may even have one "big" cache
"(bean name, user name) -> (password, principal, roles)"
DO> If you can cache the JAAS information, this will be less of a
DO> concern of course. The ability to do this may or may not depend on
DO> having a trusted client, as I mentioned above. But we wanted to
DO> implement trusted-client functionality anyway. :-)
See above.
DO> (Just as an aside. The caching piece should be a standard part of
DO> the jBoss distribution. There should be a CacheRealmManager that
DO> front-ends other RealmManagers, & the same for the
DO> EJBSecurityManager. The typical user will not implement this, or
DO> actually do any security-related programming whatsoever.)
I have to think more about it, but it looks like you've beaten by
first argument.
>> 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.
DO> Would you be able to use the "database" EJBSecurityManager and
DO> RealmMapping implementation classes that I prototyped if you
DO> could specify the database structure in a configuration file? (That
DO> was my intent.)
For password validation - yes, for realm mapping - no, we've got more
complicated structure.
DO> For the most part, I would like jBoss code to work
DO> with proprietary database and application structures as-is. :-)
I am afraid that I don't share this dream :-)
DO> If there's a good reason to go with JAAS for user-role mapping, I'm
DO> all for it. Believe me, I'm not attached to the current code or design.
DO> But if the issue is primarily GPL, it seems a bit of extra work for
DO> what we might really find to be a non-issue if we can work through
DO> the details.
Okay, answer the following question: why not use JAAS, which is
a standard authentication and authorization API, for authorization of
user access to the beans? Why invent new interfaces for that?
Why reimplement JAAS Configuration which is ready to use?
At last, why waste our time in endless license discussions?
All these arguments might be weak, but I don't break anything, I don't
replace your design, I am going to propose the GPL'ed implementation
of your interfaces, which would enable me and others to write
non-GPLed LoginModules for jBoss, because I believe this is a right
way and this is for the common good.
Also I believe that while for now JAAS seems to cause overhead,
it is very flexible and may prove to be useful in the future.
Regards,
Oleg
