2012/6/7 Christopher Schultz <ch...@christopherschultz.net>: > > I was just answering a question on StackOverflow[1] about limiting the > operations a particular user could perform when using the manager app > (e.g. deploy, undeploy, start, stop, etc.). > > It seems to me that this has come up on the users' list once or twice > in the past, and it wouldn't be a big deal to support this kind of > thing right out of the box by just defining a number of additional > roles such as: > > manager-gui-deploy > manager-gui-undeploy > manager-gui-start > etc. > > Is there any interest in doing something like this? My general feeling > is that manager access should either be allowed read-only (which is > covered by the "manager-status" role) or full read/write (which is > covered by the "manager-gui" and "manager-sript" roles) because hey, > you should trust your managers or fire them ;) > > On the other hand, if there is significant interest in this kind of > thing, we should support it out of the box. > > > [1] > http://stackoverflow.com/questions/10909471/tomcat-web-application-manager-is-it-possible-to-limit-what-each-user-role-can/10937606#10937606 >
I have several ideas where more fine-grained control would be useful. But all of them cannot be solved with configuration alone and need some checks in Java. I do not like to go there. Specifically I do not like hard-coding role names into code. I think there could be some helper component that could help in access checks. (To be discussed separately). It will need some model to map access checks to roles. What should we do with "list applications" page? Should it filter itself and hide unaccessible actions? I think that is what will be asked next. Overall, more complexity in configuration -> harder to manage and audit. There is such motto as KISS (keep it simple). The current separation of roles was introduced to split human-friendly UI (protected from CSRF) and other interfaces (which cannot be protected). Essentially it is the same as the "allow all" role of "manager" that we had until recently. If there is a way to implement your feature in a simple and transparent way, I would not mind it. But I do not see such a way. If one has specific requirements, to allow only some specific actions to "un-trusted" users, the current way is to implement a custom web application. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
