Regarding: https://issues.apache.org/jira/browse/SLING-3179 https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem
I don't see how this is adding security other than reintroducing the TrustedInfo again, just with different and more complex code. What I would like to see is reusing the whitelist-configurable loginByService() approach here: an authentication handler with pre authentication would loginByService() + impersonation – the user configured for the service would need to be able to impersonate into all the desired users, e.g. the admin user (but it would be an external config that admins can control in production). But there is some more involved - some of this is from a f2f discussion with Felix and Tobi: # Auth Handler loginByService issue This is difficult, since the call stack is not direct - the auth handler does not call loginByService directly but rather passes authinfo to the sling authenticator who does the loginByService, so the service check would see the wrong service. # Pushing loginByService down to the repo But IMHO the service check belongs into the repository bundle, not the jcrresourceresolver in sling. A new OakRepository replacing SlingRepository as an extra Oak service should provide the loginByService() (and no loginAdministrative() anymore to make a clean cut) and would live inside the private repository space, able to access oak's inner auth mechanisms to login as any user. # Big picture and goals This way there is a clear boundary between application/sling side and the repository. To control repository access for all code, not just certain areas such as JSP scripts, assuming the hacker can install bundles or trick people into doing so or simply a broken bundle in production that exposes a security risk and should be quickly disabled (revoking user mapping). With this boundary, you couldn't hack the system by adding a custom jcrresourceresolver service allowing any logins. For this btw, any other trusted login trick into JCR must be disabled (not sure if the Subject.doAs is prone to that). The only thing you could do is to replace the entire repository bundle - but there should be a way to make that fruitless. # loginByService can still be circumvented And importantly, the loginByService() check can be circumvented if you can get the bundle context / service reference from another service that has a loginByService user mapping. There should be a way to make that safe: - It might involve some OSGi extension. However, their answer would likely be JaaS, which we want to avoid for complexity reasons. - Another approach could be to look at the call stack for package names - but these could be faked (private space in OSGi bundle could use same package names) and it's not sure which call stack entry to look at. The service user mapping would require both the package name plus bundle (+ optional service id) to check for both at the same, although it seems you could mix both as well (get bundle context from somewhere else + fake package name). - Maybe something else, or maybe a little part of JaaS that just gets us this verification in a safe way. # LoginModule with a loginByService check One could also copy the idea of loginByService for a special pre auth LoginModule that would have a whitelist which of the sling auth handlers are alllowed to use it to login as any user. But IMO it would be nicer to have a single concept, because in the end (from the view of the repository) there is no difference if that service is some background process or a auth handler for creating a request session. And the question on making the loginByService verification safe (point above) would apply here as well, so better to have it in one place so it needs only be solved once. Cheers, Alex
