2012-05-23 14 views
5

Estoy tratando de manejar una situación cuando después de una autenticación exitosa con el proveedor de OpenId descubro que no hay una cuenta en mi db asociada con el identificador de usuario de openId.Spring security openId support y user deauthentication

¿Puede decirme cómo debo manejar la situación. Ahora, estoy mostrando el formulario de registro y le pido a un usuario que cree una cuenta. Sin embargo, tengo un problema con el estado de autenticación del usuario, ahora se lo ve como autenticado por la clase SecurityContext de primavera.

¿Cómo desactivo al usuario en la acción de mi controlador antes de redireccionar a '' registrar nueva página de usuario ''? ¿Este enfoque es bueno o debería hacerlo de alguna otra manera?

Respuesta

2

Ok, por lo que separar la autenticación de la autorización como se mencionó en la publicación de Samuel fue muy útil. Sin embargo, todavía hay muchos errores y encontré que la desauthentication todavía es un deber porque no hay una manera fácil en la primavera para agregar nuevos roles al usuario. Por lo tanto, la forma más fácil es obligar al usuario a iniciar sesión de nuevo y dejar que la primavera asuma la asignación de roles durante el inicio de sesión.

Para usuario Anular la en la seguridad de resorte que tiene que invocar:

SecurityContextHolder.clearContext(); 

como una alternativa que puede lanzar una excepción en su aplicación UserDetailsService (ver más abajo). Tiene la desventaja de que se desauthenticaría al usuario y se perderían los datos de contexto del usuario por lo que sería imposible hacer coincidir el nuevo usuario con la cuenta abierta durante el proceso de creación de una nueva cuenta local. Y debe coincidir con esas cuentas después de iniciar sesión con el nombre de usuario y la contraseña tradicionales. Mi solución fue desauthenticar al usuario justo después de crear una nueva cuenta.

Con el fin de otorgar funciones de usuario (privilegios), tiene que anular UserDetailsService, en caso de que alguien encuentre esto útil aquí es mi aplicación:

public final class MyUserDetailsService implements UserDetailsService { 
    private final UsersDao usersDao; 

    @Autowired 
    public UserDetailsServiceImpl(final UsersDao usersDao) { 
     this.usersDao = usersDao; 
    } 

    @Override 
    public UserDetails loadUserByUsername(final String username) {  
      UserEntity user = usersDao.getUserByOpenIdIdentifier(username); 
      if (user == null) { 
        // there is no such user in our db, we could here throw 
        // an Exception instead then the user would also be deuthenticated 
        return new User(username, "", new ArrayList<GrantedAuthority>()); 
      } 

      //here we are granting to users roles based on values from db 
      final Collection<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>(); 
      authorities.add(new SimpleGrantedAuthority(user.getUserType().toString())); 

      final UserDetails result = new User(username, "", authorities); 

      return result; 
    } 
} 
1

Creo que podría estar mezclando dos conceptos: autenticación y autorización. La autenticación es saber quién es el usuario, la autorización es el derecho a usar el acceso a un recurso de una función.

En la seguridad de la primavera, estos dos conceptos son ejecutadas por el gestor de autenticación de y la acceso en la toma de gestor de.

El hecho de que un usuario no exista en su base de datos no es una razón para negarle su identidad: ¡sin desauthentication! Pero ser autenticado puede ser un criterio en la gestión de decisiones de acceso. Ejemplo: el AuthenticatedVoter.

No se debe tocar en la autenticación, pero personalizar el acceso en la toma de gestor de aplicar las siguientes reglas:

  • Un usuario que existe en su base de datos tiene acceso a todo excepto característica de creación de la cuenta
  • Un usuario que no existe en su base de datos solo tiene acceso a la función de creación de cuenta.

Esto tiene que ver con la administración de acceso, no la autenticación.

Lea más en http://static.springsource.org/spring-security/site/docs/3.0.x/reference/ns-config.html#ns-access-manager

PS: La documentación no es exhaustiva en seguridad de la primavera, pero el código fuente es muy legible. Mi consejo es verificarlo y observar la implementación de los elementos que necesita personalizar.

Cuestiones relacionadas