Might be slightly OT, but still: there is always a repository.loginAdminstrative() to do all kinds of things. So if you can deploy code, you can do anything. To improve on that over the long term, I think we should have configurability on the repository infra level, which can do what login.
With the login as service functionality this is IMO already given - a customer could simply have a fixed whitelist of services with their corresponding users, but any new service code (or script doing loginAdministrative()) would not work. The second part are the authentication handlers, which could use the same configurable trust mechanism, and use impersonation in case they are pre-authenticated in any form (either it is an SSO where the authentication already happend outside the sling instance, or it is a more complex authentication that needs to be done in a sling authentication handler and is hard to do in a Jackrabbit LoginModule etc.). So nobody can inject a new authentication handler that isn't explicitly configured. Of course there is probably a long way to make sure no other ways exist to get a admin session (like services leaking the session etc.), but then there would be a clear boundary to work towards. AFAICS there are currently so many ways between authentication handlers and JCR login (deprecated trusted credentials, null login, sudo, user.identified, passing a jcr session, ....) and to clean that up needs some clear goal IMO. Cheers, Alex On 13.12.2013, at 01:44, Antonio Sanso <[email protected]> wrote: > hi Felix, > > thanks for your comments > > On Dec 13, 2013, at 10:31 AM, Felix Meschberger <[email protected]> wrote: > >> Hi >> >> Am 13.12.2013 um 09:38 schrieb Antonio Sanso <[email protected]>: >> >>> hi *, >>> >>> I (finally) started to give a look into the Authentication Handler >>> Credential Validation tracked in [0]. >> >> Thanks ! >> >>> >>> I kind of like the overall design I would have a question regarding the >>> String IDENTIFIED = "user.identified"; property. >>> >>> I was wondering if we do need this property or we can replace with >>> something like AuthenticationInfo with empty >>> ResourceResolverFactory.PASSWORD and present ResourceResolverFactory.USER >>> Having this property is not a big deal but since we do already "threat" >>> SimpleCredential differently in the JcrResourceProviderFactory this might >>> be IMHO feasible. >>> >>> At the end of the day a pre-authenticated user is someone that knows his >>> username but not his repository password so it would not be too wrong >>> conceptually. >>> From the other hand I already fear somebody doing something like >>> >>> new AuthenticationInfo(HttpServletRequest.FORM_AUTH, >>> user,getPassword()); >>> >>> and for some unexpected reason getPassword is null. >> >> Right. But the spec for the user.password property in the >> ResourceResovlerFactory states that >> >>> If this property is missing an empty password is assumed. >> >> and we don't want to prohibit empty passwords on this level. >> >> And then there is the other user whoe does: >> >>> ResourceResolverFactory.getResourceResovler(new Map<String, String>(){{ >>> put("user.name", admin); >>> }}); >> >> which makes for a great privilege escalation. > > right but with the user.identified property > >>> ResourceResolverFactory.getResourceResovler(new Map<String, String>(){{ >>> put("user.name", admin); > put("user.identified", "true"); >>> }}); >> > > > will technically be the same escalation. > In both case the privilege escalation guard should be in place … > > As a side comment the security model we have in place assumes that if > somebody there is not much we can do if somebody has the ability to write and > deploy code… > So for sure having the privilege escalation guard is good but it would not > be the panacea for everything. > > But in any case empty password or property would not change the overall > proposal, so let's stick with the property ;) > > regards > > antonio > > >> >>> >>> Said that also using the repository somebody can have >>> repository.login(getCredentials()); with getCredentials() being null >> >> In this case the API spec of hanlding null credentials applies, which >> assumes the call context would provide the Subject to use for login (see the >> idea outlined in the wiki page on how to implement the support >> user.identified in the Jackrabbit Server Repository bundle. >> >>> >>> Moreover we can still partially prevent this continuing using the privilege >>> escalation guard. >>> >>> WDYT? just a thought keeping the String IDENTIFIED = "user.identified"; >>> property would not be a big deal as well…. >> >> I prefer to have a new property because it is a special and new user case >> apart from regular username/password authentication. >> >> Whether the proposed property name "user.identified" is actually a good one >> is another question, though ;-) >> >> Regards >> Felix >> >>> >>> regards >>> >>> antonio >>> >>> [0] >>> https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem >> >
