I almost hesitate to admit this (ok, not really), but... Alan and
I talked by phone and discussed some of the security issues. I think we
boht have some ideas on bigger and better things for the long term, but in
the short terms, our plans are to address:
* GERONIMO-424: support multiple LoginModules
* GERONIMO-410: revise getUserPrincipals/getGroupPrincipals
* GERONIMO-430: genericize security realms
* GERONIMO-454: automatic role mapping based on group name=role name
In the process, I think we'll knock out a couple more of the open
issues, but that's almost a side effect.
Our plan is to have one generic security realm class, with logic
for handling a set of login modules, each of which is a "pure JAAS login
module" (no fancy Geronimo stuff). The security realm will also have a
optional configurable "realm editor" class, that will let you do things
like add or update users via an API. This will result in:
* security realm: Geronimo-specific, login module neutral
* login module: Geronimo-independent, login-backend-specific
* realm editor: Geronimo-specific, login-backend-specific
In short, an admin with an existing JAAS LoginModule can drop it
in with our generic security realm, and it will work, but without the
fancy editing features. Those could be implemented separately, but would
be Geronimo-specific. We will also support LoginModules that do things
like auditing and lockout and password credential population, so you'd be
able to combine a custom LoginModule with one of the standard value-added
LoginModule services and configure the generic security realm with that.
We will attempt to do this without breaking backward compatibility
with the security realm API for now, though the security realm
configuration in the deployment plans will need to change a bit, and we're
going to mark the getXXXPrincipal() methods of the security realms as
deprecated (to be removed after M3, perhaps for M4).
Aaron
