On 17 January 2014 10:37, Lars Krapf <[email protected]> wrote: > 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,
What was the problem with TrustedCredentials ? I might be thinking of the wrong thing and you might be talking about something different. I am thinking of a class that implements Credentials that is trusted by whatever logs into the repository. That class is available via factory service that looks at who is calling it and does some basic checking (eg get the byte code of the caller and sha1 it, or anything else that verifies trust between the caller and the service, but doesn't rely on the JVM for that verification). That class seals its contents against tampering on construction and does not require a password. Anything that needs to get trusted credentials is configured to be allowed access, in a place that the JVM cant tamper with. (ie OS file containing sha1s of the class defs not writable by the owner of the JVM process) I am assuming (from memory) that Credentials can be added to AuthenticationInfo and used by whatever repository (JCR2/Oak/etc) chooses to trust them during the login operation. I am not thinking about JAAS... because that hurts my brain, ;) Ian > (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 >
