Announcement Announcement Module
Collapse
No announcement yet.
Spring Security 3.0 Remember me Token based not working Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Security 3.0 Remember me Token based not working

    I have the following setup for Spring Security in 3.0. If I change the remember-me element to datasource-ref instead of key, it works great, but the token based doesn't do anything. The debug log doesn't contain any information about writing or generatigna token except the following line just as the user logs in. I get the same result in Firefox and in IE, the autologin doesn't work, it makes me login again after closing the browser. The PersistentToken works just fine.

    2009-09-16 15:24:04,661 DEBUG [org.springframework.security.web.authentication.Ab stractAuthenticationProcessingFilter] Authentication success. Updating SecurityContextHolder to contain: org.springframework.security.authentication.Userna mePasswordAuthenticationToken@c74d53ae: Principal: com.project.por.ExtUserDetails@1b601b60: Username: joeschmo; Password:

    <security:http use-expressions="true" auto-config='false'
    realm="cip" entry-point-ref="authenticationProcessingFilterEntryPoint">


    <security:intercept-url pattern="/login.jsp*"
    filters="none" />

    <security:intercept-url pattern="/logout.jsp*"
    filters="none" />

    <security:form-login login-page='/login.jsp'
    default-target-url='/index.jsp' always-use-default-target='true' />



    <!--
    <security:intercept-url pattern="/*.jsp"
    access="hasRole('ROLE_WEB_PROMISES_INQUIRY')" />
    -->

    <security:intercept-url pattern="/portal.jsp"
    access="hasAnyRole('ROLE_Teller-Users','ROLE_iArchiveViewer_Backoffice','ROLE_Navi gator Support')" />



    <security:intercept-url pattern="/"
    access="hasAnyRole('ROLE_Teller-Users','ROLE_iArchiveViewer_Backoffice','ROLE_Navi gator Support')" />

    <security:intercept-url pattern="/index.jsp"
    access="hasAnyRole('ROLE_Teller-Users','ROLE_iArchiveViewer_Backoffice','ROLE_Navi gator Support')" />

    <security:intercept-url pattern="/rest/**"
    access="hasAnyRole('ROLE_Teller-Users','ROLE_iArchiveViewer_Backoffice','ROLE_Navi gator Support')" />

    <security:intercept-url pattern="/RPCAdapter/**"
    access="hasAnyRole('ROLE_Teller-Users','ROLE_iArchiveViewer_Backoffice','ROLE_Navi gator Support')" />

    <!--
    <security:intercept-url pattern="/rest/transaction/payment/cancel/**"
    access="hasRole('ROLE_WEB_PROMISES_INQUIRY')" />
    -->


    <security:intercept-url pattern="/**" access="permitAll" />


    <!-- <security:logout logout-success-url="/" invalidate-session="true" /> -->


    <!--
    <concurrent-session-control max-sessions="1"
    exception-if-maximum-exceeded="true"/>
    -->

    <security:remember-me key="bbvaCompass" token-validity-seconds="864000" />


    <!-- <security:remember-me key="BBVACompass" token-validity-seconds="864000"/>-->

    <!-- <http-basic /> If you want to use basic authentication-->
    </security:http>

  • #2
    Theory why this isn't working

    Luke, I need someone to confirm my theory. This may explain my remember-me problem and active directory.


    I think this is our problem with the token based approach. Active Directory is configured to make the userPassword attribute inaccessible via the attributes. This doesn't matter in the PersistentToken because on a successful login, the value of the password entered is hashed and stored in the database, but that functionality doesn't exist in the Token based approach for security reasons. The code needs to be able to get the hashed password from active directory so that it can store that in the cookie and use it for autologin, but it can't get it, so it refuses to store a plain text password or hash it itself and store it since it would distribute the hash to a cookie, resulting in the ability of someone to open the cookie and crack the password. It kinda makes sense. I don't know if I am right though...this is mostly theory and what I could figure out by looking at code. I am going to keep looking at it, but I believe in order to make it work, you have two choices.

    1. Write a custom remember me implementation that does it, but I don't know how you would do this unless you stored the password as clear text in a cookie.
    2. Have some centralized persistence mechanism that you can rely on.

    //LdapUserDetailsContextMapper

    Object passwordValue = ctx.getObjectAttribute(passwordAttributeName); //userPassword

    logger.debug("User Password: " + passwordValue);
    if (passwordValue != null) {
    essence.setPassword(mapPassword(passwordValue));
    }

    Comment


    • #3
      I confirmed it, some warning log messages need to be added

      I confirmed my theory. Active Directory isn't allowing access to the password, so the TokenBasedServices just ignore.

      Luke Taylor - maybe a warning message to the log would be appropriate in this case to let someone know that TokenBasedServices cannot continue because the password is not available? This would be extremely helpful in the case of LDAP authentication considering the password may or may not be available via the authentication provider.

      The LdapUserDetailsMapper should probably also have a warn message stating that the password is null when it tries to set it on the UserDetails Object.

      //LDAPUserDetailsMapper
      Object passwordValue = ctx.getObjectAttribute(passwordAttributeName);

      if (passwordValue != null) { //prob need a warning here is null
      essence.setPassword(mapPassword(passwordValue));
      }

      essence.setUsername(username);


      //TokenBasedRememberMeServices onLoginSuccess


      String username = retrieveUserName(successfulAuthentication);
      String password = retrievePassword(successfulAuthentication);

      // If unable to find a username and password, just abort as TokenBasedRememberMeServices is
      // unable to construct a valid token in this case.
      if (!StringUtils.hasLength(username) || !StringUtils.hasLength(password)) { //prob need a warning here as well
      return;
      }

      Comment

      Working...
      X