Not much into all of this but here goes...
Den 08-06-2012 13:06, Konstantin Kolinko skrev:
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.
Eventually you would have to hardcode something right? Unless the
component is a way of overriding/extending the existing checks for
manager-gui and manager-script in java (ie. not some config file since
the checks would need some hardcoded stuff to identify the right roles
etc. in the config).
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.
That would be quite trivial wouldn't it?
Overall, more complexity in configuration -> harder to manage and audit.
True
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.
Well since the manager-gui vs. manager-script split has already been
done, why not use more fine-grained options (ie. manager-deploy,
manager-redeploy etc. and then maybe let manager-gui and/or
manager-script roles decide when those other roles apply (ie. UI og
script version of the deploy, redeploy etc.)). This would mean that you
need manager-gui and manager-??? in order to have the rights (maybe let
manager-all be default if no specific role is applied besides gui/script
role).
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
Med venlig hilsen/Kind regards
Casper W. Schmidt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
