Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of knst.kolinko@gmail.com
 designates 209.85.210.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FD0F4CC.6050202@christopherschultz.net>
References: <4FD0F4CC.6050202@christopherschultz.net>
Date: Fri, 8 Jun 2012 15:06:40 +0400
Message-ID: 
 <CABzHfVkm=oXEbXoa0j2MqrVyHtbZa9vxpTg8XVMtMpkDbxL4xQ@mail.gmail.com>
Subject: Re: [POLL] Finer-grained "manager" user-access privileges?
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/6/7 Christopher Schultz <chris@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:
>
> =A0 manager-gui-deploy
> =A0 manager-gui-undeploy
> =A0 manager-gui-start
> =A0 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-manage=
r-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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org