Trygve Laugstøl wrote:
Jörg Henne wrote:
Hi all,
especially with respect to the JBoss SAR, but also in conjunction with
other kinds of deployment, I think it is rather unfortunate to require
the super-user password to be supplied in the startup configuration.
With the SAR, one needs to tweak the jboss-service.xml file, living
inside the SAR archive, after the super-user password has been changed.
To make the pains even worse, I have several other services running on
JBoss which also depend on the directory. In order to enable
authorization of remote accesses to the directory without reverting to
a default, non-user-configurable super-user password, I have to unpack
the SAR, update the service configuration to include the updated
password and re-pack the SAR for all services during installation.
To fix this problem, IMHO there should be the option to let all in-VM
accesses by-pass authentication and authorization. In fact, I think
this should be the default way of operation, as cases, where in-VM
authorization is required, could be covered by using the standard
SecurityManager to force non-trusted accesses to use the non-local
interface.
This problem may be addressed already by the switch away from JNDI for
internal accesses. But while we're not there, I wonder whether there
is a work-around to get rid of the in-VM authentication requirement.
Oh, and while I'm already ranting... I wonder whether it is really
desirable to have a single hard-coded, catch-all super-user instead of
installing a few ACIs. WDYT?
I like the OpenLDAP way where you have the ability to ser a "root" DN
and password but you'll remove that once the DB has been set up. The
server will after that authenticate the user against the users in the
database thus totally removing the need for any external password.
It has two nice features: you can give ADS admin rights to any user, and
any ADS admin will have a single password for both logins and ADS
maintenance.
This does sound like a nice approach. There is only one problem with
implementing this. The hairy intertwined JNDI code that is a mess
inside the server now seems to keep the admin password in various
environment Hashtables.
If this can be fixed/sorted out quickly then I'm up for implementing
this kind of behavior.
Alex
