WebConsole Authentication (was: [DISCUSS] switching off Basic Auth as default?)

[Felix Meschberger <fm...@gmail.com>]

Hi,

Let me just answer this side-track:

On 05.10.2010 15:57, Justin Edelson wrote:
> On 10/5/10 4:44 AM, Mike Müller wrote:
>> Hi
>>
>> As of the discussion in [1] I like to start a new discussion
>> about whether to disable or enable Basic Auth per default.
>> The initial reason to disable it, were the problems appeared
>> in the Sling Explorer after logging in under /system/console
>> with Basic Auth (SLING-1765 [2]).
> To boil it down, the problem identified in SLING-1765 is that if a user
> logs into the OSGi web console and then visits any Sling application
> (including, but not limited to, the Sling Explorer), the user is still
> logged in.
> 
> There are three things which come to my mind about this:
> 1) The problem is that the Felix web console uses Basic Auth, not that
> Sling supports preemptive Basic Auth. Therefore, we should be changing
> the web console, not Sling's default configuration.

Makes perfect sense. Read on ...

> 
> 2) Couldn't you work around this by removing the
> org.apache.sling.extensions.webconsolesecurityprovider bundle and making
> it so that the Jackrabbit and Felix admin passwords weren't the same?

The problem is that the web console right now only supports HTTP Basic
authentication and is not as pluggable with respect to authentication as
I would like it to have.

In essence, the Web Console itself reads the HTTP Basic authentication
header and passes the username and password to the security provider.
The only thing added by the Sling webconsolesecurityprovider is support
to authenticate the username/password against the repository.

What we would need here is an extended support interface to actually
allow the Sling Authentication mechanism to fully plug-in and thus allow
for the Sling's extended functionality.

This has just not been done yet ...

> 
> 3) Aren't we talking about a relatively small number of advanced users?
> The OSGi web console doesn't have any kind of RBAC, so I can't imagine

Well, not fully RBAC, but there is a simple hook in the Security
Provider interface to implement some kind of RBAC.

Regards
Felix

> we're talking about end users or even normal content editors being
> impacted here. If someone can be trusted to muck around with the OSGi
> web console, they should be able to understand how to resolve the
> scenario described.
> 
>>
>> With Basic Auth on we've got serveral issues in the browsers:
>> - Some browsers pass credentials even on parent paths 
>> where  credentials should not be sent. 
>> - Logout is mostly a problem
>>
>> With other clients than browsers these issues doesn't exist.
>>
>> I think we agree on the fact that it would be better/safer
>> to disable Basic Auth if there would not be a backward
>> compatibility issue with it. 
> I don't agree with this at all. IMHO, Basic Auth is preferable for
> command-line tools, scripts, and the like.
> 
>>
>> What crossed my mind is, that it would be very pratical to
>> have something like a conf file where you can overwrite 
>> defaults from components as you wish. The conf file should 
>> be placed into the Sling launchpad which reads the properties
>> and overwrites the defaults. But that's a little bit off topic here,
>> but would solve the problem that someone has to patch
>> the source only because of another default value...
> See http://markmail.org/message/pvria2dxnifmllmu. I've been short on
> time and trying to get the Emma integration done, but as soon as that's
> finished, I can start integrating the ConfigAdmin/Launchpad code.
> 
> Without this support, you can pretty easily do something similar with a
> component like this: http://gist.github.com/611550
> 
> Justin
> 
>>
>> [1] http://markmail.org/thread/nmcjhvq46ihok7p2
>> [2] https://issues.apache.org/jira/browse/SLING-1765
>>
>> best regards
>> mike
> 
>