Actually, I don't think this is a common scenario - web users are usually not Unix users on your application server ?
But anyway, JBoss can do anything on your server a Java application can do - no more, no less. Meaning, if JBoss is not run with root privileges (and it shouldn't run as root in a production environment), it will have no way of reading the system's password file.
By the way, if I were the system administrator of your system, I would refuse (or at least be very skeptical) about any web-application where the root password of the server is used. Have you considered storing your users in an LDAP instead? (www.openldap.org :) )
Of course you are right in that web users are usually not UNIX-users of an application server. But this is only true as long as you are developing an internet-application. What I'm trying to develop is an intranet-application, so all users of our intranet-web-application will be those of our UNIX-environment. Users from outside our intranet should be mapped to a guest-account.
The only thing I'd like to have is a single-sign-on, meaning that our users do not have to remember a second username/password to use this application (most of them are swamped with only one login ;-)). Thats why I need a central store used by UNIX as well as by the application server to authenticate. We currently use NIS (not NIS+ , not passwd) so we can access the users password without running as root. This is not very secure - I know - but it's not my choice.
By the way, what I said about UNIX-user 'root' had only to be taken as an example (a very poor one, I admit). In production environment I would like to have a UNIX-group 'appadmin' to do the application administration stuff.
So after all I still have the need to map roles to UNIX-groups and I have not idea how to do this.
> So after all I still have the need to map roles to
> UNIX-groups and I have not idea how to do this.
Actually, I think you have a more fundamental problem to solve before considering role mappings : you have a Java program running on your server, preferably under non-root privileges, needing to verify a username/password on the machine (on in a NIS service somewhere).
Group belongings could be read by reading /etc/passwd and /etc/group resp. their nis counterparts, but verifying if a password is valid is more difficult since the password file (shadow or whatever) should not be world-readable.
Of course you can always do a first version where your Java program (or JBoss server) runs as root, then you should be able to read all necessary information in the system files while in your LoginModule.
this gives you a place where you can write your password validation and role mappings, for instance by reading them from /etc/passwd et al
Oops, I meant to say of course, extend that class, creating a new login module called UnixLoginModule for instance, and use that module in your auth.conf