You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Georg Henzler <gh...@apache.org> on 2019/08/13 22:20:34 UTC
[DISCUSS] Role-based permissions to Web Console
Hi,
Konrad opened the ticket [1] to provide read-only access to the web
console. I also like the idea, but maybe we can make it more flexible by
introducing roles. This could be a simple OSGi mapping configuration
(list of read-only/full-access plugins by group name). Two aspects would
have to be covered:
1. Allowing/blocking requests: The web console servlet could check if
the user is in one of the configured groups using
WebConsoleSecurityProvider.authorize() [2] (this method is there but
seems not to be used at all at the moment), check if access is
configured for the request path's plugin and if yes, allow only GET
requests for read-only and all methods for full-access plugins.
2. Showing only links/buttons that are accessible
2a. The servlet can easily calculate the correct menu for a given user
2b. To hide links/buttons for 'write requests" in read-only mode,
plugins would have to check with the "web console container" if those
links should be shown or not (could be a OSGI service call or simply a
request attribute set by the web console servlet)
I think everything except 2b could be implemented solely in the web
console bundle itself and the fallback for 2b (just showing links that
don't work if clicked) is acceptable, especially since the mapping for
certain groups can only include plugins that already support the new
mechanism.
I'd be happy to work on this, but I'd like to hear opinions/concerns
about the outlined approach first...
-Georg
[1] https://issues.apache.org/jira/browse/FELIX-6169
[2]
https://github.com/apache/felix/blob/0bfe4ca7ebc6e81f0a9f4186a7ef58df4d92b4c9/webconsole/src/main/java/org/apache/felix/webconsole/WebConsoleSecurityProvider.java#L56
Re: [DISCUSS] Role-based permissions to Web Console
Posted by Georg Henzler <fe...@ghenzler.de>.
Hi,
exactly 6 years, wow... let's not make it another 6 years until we talk
about this again! ;-)
So "LABEL:READ" and "LABEL:WRITE" looks good to me (that would be e.g.
"configMgr:READ"), for now I would not like to make it more complicated
(but as you said this leaves the option to introduce arbitrary,
plugin-interpreted strings like LABEL:SPECIAL-PERMISSION" later).
-Georg
On 2019-08-14 07:37, Carsten Ziegeler wrote:
> Hi,
>
> please note that we have opened
> https://issues.apache.org/jira/browse/FELIX-4194 for exactly this 6
> years ago :) We can use either of the two issues but should mark one
> of them as a duplicate.
>
> We added [2] initially for exactly the purpose but never implemented it
> :(
>
> I think we might need some clever way of mapping roles. A plugin is
> uniquely identifiable via its label. By default we might distinguish
> between read and write permissions, so we could use "LABEL:READ" and
> "LABEL:WRITE" for the roles to check for a plugin.
>
> Plugins might however define additional roles - a user might be
> allowed to modify a OSGi configuration but not remove or create new
> ones. Or maybe just be allowed to modify certain configurations. I'm
> not sure if we can handle all of these use cases with a first version
> but it certainly helps in having this in mind.
>
> Regards
> Carsten
>
> Am 14.08.2019 um 00:20 schrieb Georg Henzler:
>> Hi,
>>
>> Konrad opened the ticket [1] to provide read-only access to the web
>> console. I also like the idea, but maybe we can make it more flexible
>> by introducing roles. This could be a simple OSGi mapping
>> configuration (list of read-only/full-access plugins by group name).
>> Two aspects would have to be covered:
>>
>> 1. Allowing/blocking requests: The web console servlet could check if
>> the user is in one of the configured groups using
>> WebConsoleSecurityProvider.authorize() [2] (this method is there but
>> seems not to be used at all at the moment), check if access is
>> configured for the request path's plugin and if yes, allow only GET
>> requests for read-only and all methods for full-access plugins.
>>
>> 2. Showing only links/buttons that are accessible
>>
>> 2a. The servlet can easily calculate the correct menu for a given user
>>
>> 2b. To hide links/buttons for 'write requests" in read-only mode,
>> plugins would have to check with the "web console container" if those
>> links should be shown or not (could be a OSGI service call or simply a
>> request attribute set by the web console servlet)
>>
>> I think everything except 2b could be implemented solely in the web
>> console bundle itself and the fallback for 2b (just showing links that
>> don't work if clicked) is acceptable, especially since the mapping for
>> certain groups can only include plugins that already support the new
>> mechanism.
>>
>> I'd be happy to work on this, but I'd like to hear opinions/concerns
>> about the outlined approach first...
>>
>> -Georg
>>
>>
>> [1] https://issues.apache.org/jira/browse/FELIX-6169
>> [2]
>> https://github.com/apache/felix/blob/0bfe4ca7ebc6e81f0a9f4186a7ef58df4d92b4c9/webconsole/src/main/java/org/apache/felix/webconsole/WebConsoleSecurityProvider.java#L56
Re: [DISCUSS] Role-based permissions to Web Console
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
please note that we have opened
https://issues.apache.org/jira/browse/FELIX-4194 for exactly this 6
years ago :) We can use either of the two issues but should mark one of
them as a duplicate.
We added [2] initially for exactly the purpose but never implemented it :(
I think we might need some clever way of mapping roles. A plugin is
uniquely identifiable via its label. By default we might distinguish
between read and write permissions, so we could use "LABEL:READ" and
"LABEL:WRITE" for the roles to check for a plugin.
Plugins might however define additional roles - a user might be allowed
to modify a OSGi configuration but not remove or create new ones. Or
maybe just be allowed to modify certain configurations. I'm not sure if
we can handle all of these use cases with a first version but it
certainly helps in having this in mind.
Regards
Carsten
Am 14.08.2019 um 00:20 schrieb Georg Henzler:
> Hi,
>
> Konrad opened the ticket [1] to provide read-only access to the web
> console. I also like the idea, but maybe we can make it more flexible by
> introducing roles. This could be a simple OSGi mapping configuration
> (list of read-only/full-access plugins by group name). Two aspects would
> have to be covered:
>
> 1. Allowing/blocking requests: The web console servlet could check if
> the user is in one of the configured groups using
> WebConsoleSecurityProvider.authorize() [2] (this method is there but
> seems not to be used at all at the moment), check if access is
> configured for the request path's plugin and if yes, allow only GET
> requests for read-only and all methods for full-access plugins.
>
> 2. Showing only links/buttons that are accessible
>
> 2a. The servlet can easily calculate the correct menu for a given user
>
> 2b. To hide links/buttons for 'write requests" in read-only mode,
> plugins would have to check with the "web console container" if those
> links should be shown or not (could be a OSGI service call or simply a
> request attribute set by the web console servlet)
>
> I think everything except 2b could be implemented solely in the web
> console bundle itself and the fallback for 2b (just showing links that
> don't work if clicked) is acceptable, especially since the mapping for
> certain groups can only include plugins that already support the new
> mechanism.
>
> I'd be happy to work on this, but I'd like to hear opinions/concerns
> about the outlined approach first...
>
> -Georg
>
>
> [1] https://issues.apache.org/jira/browse/FELIX-6169
> [2]
> https://github.com/apache/felix/blob/0bfe4ca7ebc6e81f0a9f4186a7ef58df4d92b4c9/webconsole/src/main/java/org/apache/felix/webconsole/WebConsoleSecurityProvider.java#L56
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org