[ https://issues.apache.org/jira/browse/OAK-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710893#comment-13710893 ]
angela edited comment on OAK-793 at 7/17/13 9:38 AM: ----------------------------------------------------- 1) Null Login ------------------------------------------------------------------------------- As of Oak 1.0 Repository#login() and Repository#login(null, wspName) is no longer treated as guest login. This behavior of Jackrabbit-core is violating the specification which defines that null-login should be used for those cases where the authentication process is handled outside of the repository (-> see pre-authentication below). In order to get a full backwards compatible behavior OAK provides a specific GuestLoginModule [0] that can be added to the JAAS (or corresponding OSGI) configuration. Example JAAS Configuration: {code} jackrabbit.oak { org.apache.jackrabbit.oak.spi.security.authentication.GuestLoginModule optional; org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl required; }; {code} 2) Pre-Authentication in the LoginContextProvider ------------------------------------------------------------------------------- Like in Jackrabbit-core the repository internal authentication verification can be skipped by calling Repository#login() or Repository#login(null, wspName). In this case the repository implementation expects the verification to be performed prior to the login call. This behavior is provided by the default implementation of the LoginContextProvider [1] which expects a Subject to be available with the current java.security.AccessControlContext. However, in contrast to Jackrabbit-core the current implementation does not try to extend the pre-authenticated subject but skips the internal verification step altogether. Since the LoginContextProvider is a configurable with the authentication setup OAK users also have the following options by providing a custom LoginContextProvider: - Disable pre-authentication by not trying to retrieve a pre-authenticated Subject. - Add support for extending the pre-authenticated Subject by always passing the Subject to the JaasLoginContext - Dropping JAAS altogether by providing a custom implementation of the org.apache.jackrabbit.oak.spi.security.authentication.LoginContext [2] interface. Example how to use the pre-auth: {code} String userId = "test"; /** Retrive valid principals e.g. by calling jackrabbit API - PrincipalManager#getPrincipal and/or #getGroupMembership or from Oak SPI - PrincipalProvider#getPrincipals(String userId) */ Set<? extends Principal> principals = getPrincipals(userId); AuthInfo authInfo = new AuthInfoImpl(userId, Collections.<String, Object>emptyMap(), principals); Subject subject = new Subject(true, principals, Collections.singleton(authInfo), Collections.<Object>emptySet()); Session session; try { session = Subject.doAsPrivileged(subject, new PrivilegedExceptionAction<Session>() { @Override public Session run() throws Exception { return login(null, null); } }, null); } catch (PrivilegedActionException e) { throw new RepositoryException("failed to retrieve session.", e); } {code} 3) Impersonation ------------------------------------------------------------------------------- The OAK implementation of Session#impersonate no longer uses SimpleCredentials to transport the original Subject but rather performs the login with dedicated ImpersonationCredentials [3]. With this change the impersonation feature no longer relies on SimpleCredentials being passed to Session#impersonate call. Instead the specified credentials are passed to a new instance of ImpersonationCredentials delegating the evaluation and validation of the specified Credentials to the configured login module(s). This modification will not affect applications that used JCR API to impersonate a given session. However the following example which 'manually' builds impersonation credentials the way jackrabbit core was handling it will no longer work to impersonate an existing session: {code} SessionImpl sImpl = (SessionImpl) mySession; SimpleCredentials jrImpCreds = new SimpleCredentials("someUserId, new char[0]); creds.setAttribute(SecurityConstants.IMPERSONATOR_ATTRIBUTE, sImpl.getSubject()); Session impersonated = sImpl.getRepository().login(jrImpCreds, sImpl.getWorkspace().getName()); {code} 4) References ------------------------------------------------------------------------------- [0] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/GuestLoginModule.java [1] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/LoginContextProvider.java [2] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/LoginContext.java [3] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/ImpersonationCredentials.java was (Author: anchela): 1) Null Login ------------------------------------------------------------------------------- As of Oak 1.0 Repository#login() and Repository#login(null, wspName) is no longer treated as guest login. This behavior of Jackrabbit-core is violating the specification which defines that null-login should be used for those cases where the authentication process is handled outside of the repository (-> see pre-authentication below). In order to get a full backwards compatible behavior OAK provides a specific GuestLoginModule [0] that can be added to the JAAS (or corresponding OSGI) configuration. Example JAAS Configuration: {code} jackrabbit.oak { org.apache.jackrabbit.oak.spi.security.authentication.GuestLoginModule optional; org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl required; }; {code} 2) Pre-Authentication in the LoginContextProvider ------------------------------------------------------------------------------- Like in Jackrabbit-core the repository internal authentication verification can be skipped by calling Repository#login() or Repository#login(null, wspName). In this case the repository implementation expects the verification to be performed prior to the login call. This behavior is provided by the default implementation of the LoginContextProvider [1] which expects a Subject to be available with the current java.security.AccessControlContext. However, in contrast to Jackrabbit-core the current implementation does not try to extend the pre-authenticated subject but skips the internal verification step altogether. Since the LoginContextProvider is a configurable with the authentication setup OAK users also have the following options by providing a custom LoginContextProvider: - Disable pre-authentication by not trying to retrieve a pre-authenticated Subject. - Add support for extending the pre-authenticated Subject by always passing the Subject to the JaasLoginContext - Dropping JAAS altogether by providing a custom implementation of the org.apache.jackrabbit.oak.spi.security.authentication.LoginContext [2] interface. 3) Impersonation ------------------------------------------------------------------------------- The OAK implementation of Session#impersonate no longer uses SimpleCredentials to transport the original Subject but rather performs the login with dedicated ImpersonationCredentials [3]. With this change the impersonation feature no longer relies on SimpleCredentials being passed to Session#impersonate call. Instead the specified credentials are passed to a new instance of ImpersonationCredentials delegating the evaluation and validation of the specified Credentials to the configured login module(s). This modification will not affect applications that used JCR API to impersonate a given session. However the following example which 'manually' builds impersonation credentials the way jackrabbit core was handling it will no longer work to impersonate an existing session: {code} SessionImpl sImpl = (SessionImpl) mySession; SimpleCredentials jrImpCreds = new SimpleCredentials("someUserId, new char[0]); creds.setAttribute(SecurityConstants.IMPERSONATOR_ATTRIBUTE, sImpl.getSubject()); Session impersonated = sImpl.getRepository().login(jrImpCreds, sImpl.getWorkspace().getName()); {code} 4) References ------------------------------------------------------------------------------- [0] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/GuestLoginModule.java [1] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/LoginContextProvider.java [2] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/LoginContext.java [3] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/ImpersonationCredentials.java > Authentication: Document changes wrt. Jackrabbit > ------------------------------------------------ > > Key: OAK-793 > URL: https://issues.apache.org/jira/browse/OAK-793 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: jcr > Reporter: angela > Assignee: angela > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira