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
[email protected]
