Bill Shannon requests some ARC feedback from those knowledgeable about security on a new GlassFish 'asadmin' command line feature. Thank you for any help you can offer.
"I've implemented the technique described. I'd like to get someone to review the security aspects of the implementation as well as the server integration aspects of the implementation." Any volunteers? .............. BILL's PROPOSAL Currently in v3 the asadmin stop-domain command fails if the domain has a non-default admin user and you don't specify the user name. In v2 stop-domain would succeed in this case, as long as you were on the same machine as the DAS. The v3 stop-domain command needs to execute the command on the server (as opposed to using "kill" or something like that), which means it needs to authenticate with the server. To allow v3 to be more compatible with v2, we're considering adding a new authentication mechanism that will "only" work in the local case. Roughly, here's how this would work... On server startup, the server would generate a large random number and write it in a file that is readable only by the owner of the file (the user who started the server). Local commands, such as stop-domain, would read this file if it's available and send the number as part of the authentication information to the server. The server would accept either the normal username/password authentication, or some special username along with this number as the password. This allows anyone who can read the file to authenticate to the server. Normally this would only be the user who owns the server and is running on the same machine. First, see any holes with this approach? Second, should we generalize this approach and allow it to be used for normally remote commands as well? This means you could create a domain with a non-default admin user and in the local case you would never need to specify the admin user name or password, and yet there would be some protection against remote admin access.
