On 17.01.2014, at 05:52, Lars Krapf <[email protected]> wrote:
> When I talk about trusted credentials, I refer only to the previous
> implementation that relied
> on an attribute (configured once for the login-module(s) and once for the
> authentication handler).
> which was stored in plain-text, and had a default value that you still can
> find in many production-instances out there.
> Once that config leaks, it could easily lead to administrative compromise of
> the repo in many cases,
> so this clearly was something that needed improvement.
AFAICS, this would only protect the RMI case more. Any other non-JVM code
access, say a Jackrabbit-level Webdav, couldn't set arbitrary Credentials
attributes to set the TrustedInfo anyway.
Any other code can do the Subject.doAs as below (from the wiki [0]):
Session tmp = session = repository.loginAdministrative(workspace);
Authorizable auth = ((JackrabbitSession)
tmp).getUserManager().getAuthorizable(userName);
Subject s = new Subject();
s.getPrincipals().add(auth.getPrincipal());
session = Subject.doAs(s, new PrivilegedExceptionAction<Session>() {
public Session run() throws Exception {
return repository.login(workspace);
}
});
So all the effort for no real improvement IMO. Why not go all the way and
ensure the authentication (and this includes authorizing the pieces of code
that are allowed to do a pre-authentication, such as an SSO authentication
handler) in the repository instead of Sling?
[0]
https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem
Cheers,
Alex
