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 >
