On 16.01.2014 23:28, Alexander Klimetschek wrote:
On 16.01.2014, at 05:19, Carsten Ziegeler <[email protected]> wrote:
Eagerly waiting for a patch which implements this :)
He he :)
This isn’t meant as something we should have soon - it is meant as a goal to
guide around the jcr login mechanism discussion.
One opinion is: ah, don’t care, once code is running in the JVM, consider
everything exploited, so we can put JCR authentication and convenience
mechanisms everywhere.
My opinion is: no, write that authentication code with a clear boundary in mind
(JCR), sling/application level code can’t just login as anyone on JCR unless
the internal repository authenticates it. So that later my above vision is
simpler to reach. As a side effect, code and security configuration becomes
clearer (having to configure authentication both in Sling and Jackrabbit is
just confusing).
For most cases this is true since the Sling authentication layer is
basically responsible for credential extraction not authentication.
For some (SSO) usecases however validation has to happen on the sling
layer - so there always has to be some means of trust delegation between
these two layers.
Trusted credentials was the answer before, and using JCR
preauthentication (null-login) is hopefully soon.
Otherwise I don’t even know why we removed the TrustedInfo in the first place.
Because it is inherently insecure to have a preconfigured plain-text
admin password laying around, that needs to be changed in two places
just to establish trust.
Cheers
Lars
