There seems to be no security for the ServiceManager. Anyone who can
access the RPCRouter can access the Service Manager to deploy/undeploy
services. Additionally, anyone who can access the admin .jsp pages can
also deploy/undeploy services.
I read a suggestion that the solution to securing the ServiceManager was
to remove it completely by plugging in your own ConfigManager.
I think the base problem here is not that the Security Manager is
insecure. I think the problem is that there is no real transport-level
security for SOAP services at all, and ServiceManager just happens to be
one of those SOAP services that many people would wish to restrict access
to.
A single BASIC-level HTTP authorization would be very handy indeed. You
could password protect any methods on any TargetObjectURIs through a
simple xml configuration file explaining what roles can access any
particular method on any particular object, then another xml file to
store users, passwords, and roles they belong to.
Perhaps this "SecurityManager" could be pluggable, and the
DefaultSecurityManager would do what was described in the last paragraph,
but other SecurityManagers could be plugged in to support different
authorization methods or different credential types.
For instance, instead of reading a static user/password list and checking
a role/permission list, a plugged-in SecurityManager could query the app
server for authorization of a user... or check the system permissions
(/etc/passwd,/etc/group, where groups would be roles).
Or perhaps require credentials to be something other than passwords...
Perhaps a certificate.
The RPCRouter servlet and the admin/ .jsps would have to be changed to
talk to this Security Manager in order to prompt for a password or get a
certificate... This is really a very easy change...
I can make these changes, but don't have cvs access.. I'd be glad to
implement these changes against the current cvs tree and send diffs
however, if there is any interest at all from the project leadership,
although I might not fully understand your "vision" of the project and it
might be better done by one of your existing contributors, or not done at
all for some reason I cannot see.
Thanks,
David Green
