Configurando Spring Security

Configurando Spring Security

Hoy vamos intentar hacer un pequeño tutorial que muestre cómo configurar Spring Security en nuestros proyectos Java.

Spring Security es un framework que permitirá gestionar todo lo relativo a la seguridad de nuestra aplicación web, desde el protocolo de seguridad, hasta los roles que necesitan los usuarios para acceder a los diferentes recursos de la aplicación.

Toda la información necesaria, se puede obtener leyendo la documentación oficial de Spring. Por supuesto, la cantidad de información que aparece ahí es enorme, lo que hace tedioso su lectura. Además, para una configuración básica, no nos hace falta saber cómo configurar Spring Security para que, por ejemplo, se autentique contra un LDAP o un CAS. Por eso, intentaremos hacer un resumen y explicaremos solamente la configuración básica, dejando para otros artículos, otras configuraciones más complicadas.

Antes de continuar, hay que decir que Spring Security puede llegar a facilitar mucho las cosas dependiendo de nuestras necesidades. Se podría decir que Spring Security es declarativo y apenas hace falta programar nada y todo se configura mediante un fichero de configuración. Esto llega a tal punto que incluso no es necesario crear una página de Login, ya que Spring Security lo hace por ti. Lo único que hay que enseñarle es a recuperar los datos del usuario que se está intentando loguear en nuestra aplicación. Obviamente, si nuestra aplicación lo requiere o necesitamos personalizar algunos aspectos, Spring Security también te lo permitirá indicándoselo en el fichero de configuración.

Lo primero que debemos hacer es incluir las dependencias adecuadas en nuestro pom.xml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 <dependency>
 	<groupId>org.springframework.security</groupId>
 	<artifactId>spring-security-core</artifactId>
 	<version>3.0.5.RELEASE</version>
 	<type>jar</type>
 	<scope>compile</scope>
 </dependency>
 <dependency>
 	<groupId>org.springframework.security</groupId>
 	<artifactId>spring-security-web</artifactId>
 	<version>3.0.5.RELEASE</version>
 	<type>jar</type>
 	<scope>compile</scope>
 </dependency>
 <dependency>
 	<groupId>org.springframework.security</groupId>
 	<artifactId>spring-security-config</artifactId>
 	<version>3.0.5.RELEASE</version>
 	<type>jar</type>
 	<scope>compile</scope>
 </dependency>

El siguiente paso es habilitar Spring Security. Básicamente bastaría con ir creando filtros en el web.xml de nuestra aplicación, pero se puede convertir en ineficiente e ilegible si se empiezan a crear muchos filtros. Por lo tanto, la forma correcta de usar Spring Security, es añadiendo un único filtro en el web.xml. Así, éste delegará en los filtros que se creen en el fichero de configuración de Spring Security de la siguiente forma:

1
2
3
4
5
6
7
8
9
<filter>
     <filter-name>springSecurityFilterChain</filter-name>
     <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
 
<filter-mapping>
     <filter-name>springSecurityFilterChain</filter-name>
     <url-pattern>/*</url-pattern>
</filter-mapping>

A continuación es necesario crear el archivo de configuración de Spring Security, que llamaremos spring-security.xml.

Existen dos formas de configurar Spring Security: una 100% manual y otra algo más automática. La forma manual consiste en definir todos los filtros necesarios para su correcto funcionamiento.
La otra forma, que es la que mostraremos, consiste en usar el elemento http. Este elemento configurará por nosotros todos los filtros obligatorios, beans y la cadena de seguridad. Si además se le pone el atributo auto-config a true, configurará todos los filtros restantes necesarios para el funcionamiento.

El primero de los beans que se crea es el springSecurityFilterChain, que es el encargado de gestionar los diferentes filtros de la cadena de seguridad.

Obviamente, se pueden personalizar los filtros que se configuran automáticamente e incluso añadir los nuestros propios. Esto se realiza anidando un nuevo elemento en el http. Con el custom-filter, se pueden añadir nuevos filtros, así como posicionarlos donde sea necesario en la cadena de seguridad. Es posible que alguno de los nuevos filtros entren en conflicto con algunos de los existentes. Esto ocurrirá si estamos sobreescribiendo un filtro existente, con lo cual, habrá que poner el atributo auto-config a false.

Se define también el filtro de autenticación (authenticationProcessingFilter), que será el que permita generar la sesión, el token, etc en el SecurityContext. Probablemente, con los valores por defecto sería suficiente, pero es interesante definirlo para poder configurar una serie de propiedades importantes.

La primera y fundamental es el AuthenticationManager. Este bean, entre otras cosas, es el encargado de recuperar la información de usuario que se está intentando loguear en el sistema. Esto lo consigue mediante un provider que es necesario definir. Este provider es el que proporciona al AuthenticationManager los detalles de nuestro usuario. Así, el provider construye un objeto UsernamePasswordAuthenticationToken si la contraseña es la correcta y se lo pasa al AuthenticationManager. Éste será el que se encargue de rellenar el SecurityContextHolder. Se pueden definir varios providers según sea necesario, e incluso definir uno propio.

Otra propiedad del AuthenticationManager es authenticationSuccessHandler. De la forma mostrada, indicando SavedRequestAwareAuthenticationSuccessHandler, se redirigirá a la página que se solicitaba originalmente antes de la autenticación. Se proporciona el default por si no estaba pidiendo ninguna página en concreto.

Como habíamos dicho, utilizaremos el elemento http por ser en principio más cómodo. Si fuera necesario añadir más elementos de este tipo, para cada uno de ellos será necesario indicarle el atributo pattern, ya que de no existir, se asume el universal (pattern=”/**”), lo que capturaría todas las peticiones.
Nota: en las urls no incluir el contextPath (nombre de la app).

A continuación, se muestra un ejemplo del fichero completo (descarga):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:sec="http://www.springframework.org/schema/security"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
   	 http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-3.0.xsd">
 
 
    <bean id="authenticationProcessingFilter" class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">
        <property name="authenticationManager" ref="authenticationManager" />
        <property name="filterProcessesUrl" value="/j_spring_security_check" />
        <property name="authenticationSuccessHandler">
            <bean class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler">
                <property name="defaultTargetUrl" value="/pages/home" />
            </bean>
        </property>
        <property name="authenticationFailureHandler">
            <bean class="org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler">
                <property name="defaultFailureUrl" value="/pages/errorlogin" />
            </bean>
        </property>
    </bean>
 
    <bean id="authenticationManager" class="org.springframework.security.authentication.ProviderManager">
        <property name="providers">
            <list>
                <ref bean="myAuthenticationProvider" />
            </list>
        </property>
    </bean>
 
    <bean id="myAuthenticationProvider" class="com.cleventy.spring.filter.MyAuthenticationProvider">
        <property name="userDetailsService" ref="myUserDetailsService" />
    </bean>
 
    <bean id="myUserDetailsService" class="com.cleventy.spring.filter.MyUserDetailsService" />
 
    <sec:http auto-config="true" use-expressions="true" access-denied-page="/pages/denied"
        authentication-manager-ref="authenticationManager">
        <sec:intercept-url pattern="/login" access="permitAll" />
        <sec:intercept-url pattern="/user/*" access="hasRole('USER')" />
        <sec:form-login login-page="/login" default-target-url="/user" />
        <sec:logout invalidate-session="true" delete-cookies="JSESSIONID" logout-success-url="/" logout-url="/j_spring_security_logout" />
    </sec:http>
 
</beans>

Como se puede ver en el ejemplo anterior, es posible también definir roles de usuario que tendrán acceso a ciertos patrones de URL. Se configurará declarativamente en el spring-security.xml, pero también será necesario asignar el rol correspondiente al usuario programáticamente una vez que el login haya sido satisfactorio. El proceso, por lo tanto, sería el siguiente. El UserDetailsService recupera de base de datos la información del usuario que se quiere loguear, creando un objeto de tipo UserDetails. Entre los detalles de ese usuario, se encuentran los “authorities”, es decir, los posibles roles que tendrá el usuario. Por lo tanto, en el momento de recuperación y creación de ese objeto, es necesario también indicar los roles correctos. De esta forma, el AuthenticationProvider ya tendrá todos los datos necesarios para crear el UsernamePasswordAuthenticationToken y el AuthenticationManager sabrá si el usuario puede o no acceder a la url que solicita. Veamos la implementación de un provider de ejemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
public class MyAuthenticationProvider implements AuthenticationProvider {
 
    private UserDetailsService userDetailsService;
 
    public void setUserDetailsService(UserDetailsService userDetailsService) {
 
        this.userDetailsService = userDetailsService;
    }
 
    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
 
        UserDetails userDetails = this.userDetailsService.loadUserByUsername(authentication.getName());
        if (userDetails != null && new BasicPasswordEncryptor().checkPassword(authentication.getCredentials().toString(),
                        userDetails.getPassword())) {
            return new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
        }
 
        throw new BadCredentialsException("Bad credentials");
    }
}

Ya estamos terminando. Resta añadir el archivo recién creado al contexto para que se cargue. Esto se realiza como cualquier otro archivo de configuración.

1
2
3
4
5
6
7
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            classpath:applicationContext.xml
            classpath:spring-security.xml    
        </param-value>
    </context-param>

Se podría decir que ya tenemos todo configurado. Como habíamos comentado al principio, Spring Security incluso te genera una página de login, pero si lo que queremos es adaptar la nuestra, simplemente debemos seguir unas simples convenciones

  • el atributo action debe tener el valor “j_spring_security_check”:
    <form action="j_spring_security_check" method="post"></form>
  • el atributo name del input para el usuario debe ser “j_username”:
    <input type="text" name="j_username" />
  • el atributo name del input para el password debe ser “j_password”:
    <input type="password" name="j_password" />

Obviamente, también es posible personalizar cada uno de estos nombres preestablecidos.

Por último, y para terminar este tutorial, un usuario tiene que poder salir de la página y eliminar la sesión actual. Para esto, hay que configurar el LogoutFilter. En el spring-security.xml hay que incluir las siguientes líneas:

1
<sec:logout invalidate-session="true" delete-cookies="JSESSIONID" logout-success-url="/" logout url="/j_spring_security_logout" />

De esta forma en nuestro html, debemos definir un enlace como el siguiente para que Spring Security se encargue de todo:

<a href="j_spring_security_logout">Logout</a>

Hasta aquí este tutorial. Ha sido un poco denso, pero con paciencia podremos realizar unaconfiguración básica de Spring Security en poco tiempo.

Publicado en agosto 6, 2013

,

,

24 comentarios en Configurando Spring Security
  1. Erick dice:

    Por casualidad algun enlace para poder descargar el ejemplo completo??

  2. Daniel Perez dice:

    Hola gracias por el aporte ha sido bastante clarificante para mi.
    como antecedente estoy entrando al mundo de mvc spring y toda esa terminologia de la cual habia estado escapandome por un buen tiempo.

    mi situacion actual tengo un servidor del cual despacho varios proyectos en distintos contextos pero hechos con la misma tecnologia, clases para todo y vistas en jsp… para suponer un ejemplo tengo un proyecto que es /contabilidad y otro /recursoshumanos ambos usan una autentificacion hecha en casa de usuario y contraseñas y si todo coincide pongo los roles en sesion y listo .. pero cada uno tiene que autenticarse por su lado y ambos se usan por el mismo personal.

    aqui la pregunta es puedo levantar un contexto con el spring security y manejar un solo acceso para ambos proyectos ya sea que al logearse dependiendo del usuario lo envie a un selector de cual de las aplcaciones puede accesar y que las aplicaciones puedan tambien validar que el que acceso tiene las credenciales para estar donde tiene que estar,

    espero explicarme pero he leido un buen rato y no veo algo similar aunque en cierta forma dan a entender que si

    de antemano mil gracias por el aporte y por el tiempo que tomas para la respuesta.

  3. cperez dice:

    Hola Daniel,

    Lo que planteas es perfectamente posible.

    Una opción podría ser crear una nueva app web que tenga como dependencias todas las webapps a las que el usuario puede acceder. La nueva webapp se encargaría simplemente de realizar el login y redirigir al portal adecuado para cada usuario (o el que escoja en el selector, tal y como dices). En el momento de hacer el login el SecurityContextHolder contendrá toda la información de seguridad necesaria, que entiendo que se debería compartir con los proyectos dependientes, quedando así cubierto el segundo de los escenarios que contemplas, que el usuario no acceda a donde no pueda. Por otro lado, es posible que tengas que crear tu propia implementación de algunos de los filtros de Spring Security debido a que es un caso muy concreto y puede que requiera de lógica específica a tu situación. Repasando todos los filtros de la cadena de Spring Security, seguro que encuentras el más apropiado para colocar tu lógica (si es que al final la necesitas).

    Lamento darte una respuesta tan teórica, pero espero que te sirva de ayuda.

  4. Oscar dice:

    Hola. Un artículo muy instructivo.
    He estado implementando lo que has expuesto y me he encontrado con una par de errores en el fichero spring-security.xml.
    Parece que el problema es que los atributos ‘authentication-manager-ref’ y ‘delete-cookies’ son de la versión 3.1 de spring security.
    He tenido que cambiar el schemaLocation para que haga referencia a http://www.springframework.org/schema/security/spring-security-3.1.xsd en lugar de la versión 3.0.

    Saludos

    • cperez dice:

      Muchas gracias por tu aporte, Óscar. En realidad este artículo ya se ha quedado un poco anticuado y lo recomendable sería actualizar Spring Security a la última versión. Intentaremos revisarlo y actualizarlo.

      Gracias de nuevo.

  5. Arnold dice:

    Gente pa cuando la configuracion manual ?

  6. beatriz dice:

    Hola!
    Como puedo configurar una aplicación que este hecha en Php para que se autentique por medio de CAS utilizando spring security?

    • cperez dice:

      Hola,

      Para configurar Spring Security para que utilice CAS, puedes seguir las instrucciones de la documentación: http://docs.spring.io/spring-security/site/docs/3.0.x/reference/cas.html

      A modo de resumen, la configuración sería en dos pasos. El primero sería configurar el filtro “cas_filter” para que las peticiones pasen por el CAS. Además, también hay que configurar el “entry point” para que Spring Security “sepa” a dónde dirigir las peticiones no autenticadas y para que el usuario pueda meter su usuario y contraseña. El segundo de los pasos sería configurar un nuevo “provider”, el “CasAuthenticationProvider” que será quien permita el acceso a tu plataforma.

  7. Mario dice:

    El schema para que contenga los atributos authentication-manager y delete-cookies debería ser cambiado a
    Luego tengo otro tema, siempre utilizando 3.0.5.RELEASE tal como indican, que es el hecho de que MyAuthenticationProvider implementa de MyAuthenticationProvider y esta interface tiene otro metodo que es public boolean supports(Class arg0) pero no llegue a entender bien que hay que implementar del javadoc

    • cperez dice:

      Hola Mario,

      Efectivamente, este ejemplo se ha quedado antiguo y sería recomendable actualizar la versión de Spring.

      En cuanto al método supports de la interfaz AuthenticationProvider, sirve para indicar si el authenticationProvider concreto es válido. La documentación dice esto:

      Returns true if this AuthenticationProvider supports the indicated Authentication object.
      Returning true does not guarantee an AuthenticationProvider will be able to authenticate the presented instance of the Authentication class. It simply indicates it can support closer evaluation of it. An AuthenticationProvider can still return null from the authenticate(Authentication) method to indicate another AuthenticationProvider should be tried.
      Selection of an AuthenticationProvider capable of performing authentication is conducted at runtime the ProviderManager.

      Es decir, por poner un ejemplo, podría pasar que tu proyecto necesitase varios authenticationProviders para cubrir diferentes tipos de autenticación. En ese caso, estarían declarados en la lista de providers del bean authenticationManager (ProviderManager). Al tener varias opciones para realizar la autenticación, el authenticationManager escogerá aquel que se adapte mejor a cada situación y esto lo hace llamando al método supports. Lo habitual sería asegurarse de que el objeto que recibe el método supports, contenga el mismo token que se está utilizando (en el ejemplo UsernamePasswordAuthenticationToken).

      Espero haberte ayudado.

  8. YS dice:

    ¿Como lo puedo hacer si quiero crear dos login distintos, el segundo invocando a un controlador?

    • cperez dice:

      Hola,

      Puedes crear tantos login distintos como quieras declarando los respectivos beans LoginUrlAuthenticationEntryPoint. Por ejemplo:


      A continuación, declararías un por cada entry-point que tengas (ojo, con la propiedad auto-config=”false”).
      Dependiendo de tu caso en concreto, seguramente te interese también tener un Provider independiente para cada tipo de login (por ejemplo si la comprobación del usuario y contraseña se hace de forma diferente). Una vez declarado cada uno de ellos, simplemente hay que añadirlo a la lista de providers del authenticationManager.

      Espero haberte ayudado.
      Saludos

  9. Saby dice:

    Hola. Primero, gracias por el aporte. Ya llevo un par de años trabajando con esta infraestructura; y como mencionaron anteriormente, he tenido que hacer algunas modificaciones para flexibilizar el uso del spring-security. Como todos saben, hay ocasiones ne la que es necesario almacenar los datos de acceso e inicio de session (usuario, fecha y hora de acceso, etc). Hasta ahi no tengo problema alguno, el problema lo tengo al tratar de guardar la fecha y hora de cierre de session. como han visto en el ejemplo, el spring security solo realiza un “delete cookies” y asi se cierra sesion. Pero no tengo idea de como obtener la fecha y hora del cierre de sesion para guardarlo en la base de datos. No se si me explique correctamente. Agradecería que me ayuden con eso. Gracias de antemano.

    • cperez dice:

      Hola, Saby,

      La verdad no me había planteado esa casuística y a priori no te sabría decir la solución adecuada.

      De primeras lo que se me ocurre es que crees tu propio filtro y lo incorpores a la cadena de filtros de Spring Security. La siguiente decisión sería dónde colocar tu filtro en la cadena. Uno de los múltiples filtros de la cadena de Spring Security es el LogoutFilter. Éste podría ser un buen sitio para tu lógica, ya que se ejecutará cuando el usuario cierre la sesión. Veo varias opciones en cuanto a la posición, pero no tengo claro cuál sería la mejor: justo antes, justo después o directamente en sustitución del LogoutFilter.

      En el siguiente link, en el apartado “2.3.5 Adding in Your Own Filters”, puedes ver cómo se declararía y colocaría un filtro propio, además de todos los filtros disponibles: https://docs.spring.io/spring-security/site/docs/3.0.x/reference/ns-config.html

      Espero haberte ayudado. Si te apetece, coméntanos qué solución has implementado finalmente.

      Saludos

  10. Guillermo dice:

    Buenos días CPerez,
    Me gustaría saber si podrías ayudarme en un problema que tengo en una aplicación que estoy desarrollando.
    Estoy interceptando con el SpringSecurity una URL del tipo:

    Entonces funciona bien cuando alguien introduce esta dirección directamente en el navegador, con funciona bien, quiero decir que te pide login y pass, y si lo pones correctamente entras.
    Pero hay otra forma de entrar en la aplicación que es introduciendo una dirección con Token, que me lleva a un servlet creado por mi, que según un token u otro te redirige a otras páginas.
    El problema que estas páginas a las que redirige el servlet son “hijas” o comparten la url que se intercepta en el spring security. (/client/index.html&mode=1 o /client/index.html&idIncidencia=2)
    Entonces aunque introduzcas la dirección del token correctamente al redirigir con:
    response.sendRedirect(request.getContextPath() + “/client/index.html&mode=1”);
    pues te vuelve a mandar al login de spring-security para que te autentiques “otra vez” y ya te redirige.
    Pero yo lo que quiero es saber si puedo hacer yo alguna redirección sin pasar por spring-security aunque esté definida en las intercepciones del spring.

    Un saludo. Gracias.

    • Guillermo dice:

      Esta es la URL del tipo que no he especificado en el mensaje anterior:

      • Guillermo dice:

        Parece que no me deja copiarlo, te lo pongo separado por espacios:
        s e c u r i t y :i n t e r c e p t – u r l p a t t e r n = ” /
        c l i e n t / i n d e x . h t m l ? v a l i d o = t r u e ” a c c e s s =
        ” I S _ A U T H E N TI C A T E D _ F U L L Y “

    • cperez dice:

      Hola, Guillermo,

      Espero haber entendido bien el problema.

      Voy a suponer que si el usuario hace una petición con el token, significa que en realidad el usuario tiene permisos suficientes, es decir, como si estuviera autenticado. En ese caso, yo lo que haría sería que en tu servlet que recibe el token, hagas la autenticación de spring security. La idea es que, al estar el usuario autenticado, Spring Security ya no te redirigirá al login.

      Para hacer esa autenticación “manual” tienes que inyectar el AuthenticationManager en el servlet y llamar al método “authenticate”. La duda ahora viene si con en el servlet tienes toda la información necesaria para construir el parámetro “Authentication” del método. Si es así, no habrá problema porque el authenticationManager utilizará el mismo provider que ya tienes definido. En otro caso, lo más probable es que estés obligado a crear un provider nuevo que permita la autenticación a través de tu token. Puedes incluir en el authenticationManager todos los providers que desees. Él será el encargado de usar uno u otro en función de los datos que reciba (en tu caso token vs usuario/contraseña). En concreto, esto lo sabe gracias al método “supports” del provider. Por lo tanto, tendrás que extender el AbstractAuthenticationToken para crear tu nuevo “tipo” de autenticación.

      Es mucha información y son muchos pasos los que te comenté. Si te parece, intenta avanzar e intentamos ayudarte si te vuelves a atascar.

      Espero haberte ayudado algo.
      Saludos

      • Guillermo dice:

        Buenas tardes CPerez,
        Muchas gracias por tan rápida contestación.
        Si he entendido bien todo, lo que estoy intentando, es desde mi servlet, y una vez que he comprobado que mi Token es válido, que llame al método:
        public Authentication authenticate(Authentication authentication) throws AuthenticationException de la clase:
        public final class ActiveDirectoryLdapAuthenticationProvider extends AbstractLdapAuthenticationProvider

        Para ello importo la clase en el servlet,pero al intentar llamar al método authenticate, pasándole de parámetro una (authentication), me da error, y no se como arreglarlo, porque me dice que no puedo instanciar un objeto del tipo Authentication en esta clase.

        ¿Alguna ayuda? Muchas gracias de antemano.
        Un saludo.

        • cperez dice:

          Hola, Guillermo,

          Se me ocurren dos detalles que espero que te puedan ayudar.

          Sobre el parámetro Authentication, si te fijas, es una interfaz, con lo cual no la puedes instanciar tal cual. Ahí deberías instanciar alguna de sus implementaciones, como por ejemplo UsernamePasswordAuthenticationToken, o la que se te adecúe más a tu lógica. De hecho, ActiveDirectoryLdapAuthenticationProvider extiende de AbstractLdapAuthenticationProvider, cuyo método “supports” te indica qué tipo de Authentication soporta. En este caso es:
          public boolean supports(Class< ?> authentication) {
          return UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication);
          }

          ¿Qué significa esto? Que este provider necesita que le pases un Authentication de tipo UsernamePasswordAuthenticationToken, así que construye un objeto del tipo anterior y pásaselo como argumento al método “authenticate”.

          El otro punto que te quería comentar es el tema de llamar directamente al provider. Si te funciona, supongo que se podrá hacer, pero si te encuentras con algún problema ahí, piensa en hacerlo a través del AuthenticationManager. Incluso, si quieres ir un paso más allá, podrías mover todo tu servlet a un filtro de SpringSecurity y ahí tendrías todos los objetos necesarios del framework.

          Espero haberte ayudado. Buena suerte!

          • Guillermo dice:

            Buenos días CPerez,
            Gracias por contestar, estoy llamando, como me dijiste al metodo authenticate desde mi servlet, y en este método le paso un usuario y password mio, para que al entrar por token me llame a este método con unos parámetros que pueda evaluar yo mismo. Cuando llega a este metodo authenticate, con mis parámetros, hago que devuelva esto:
            return createSuccessfulAuthentication(userToken,this.getUserNew(“usuarioAutenticado”,”passwordAutenticada”));
            y vuelve al servlet y redirijo a la pagina que quiero, pero sigue pidiendome autenticación…. a si que no se que hacer, nose si esque no estoy autenticando correctamente, o que no le estoy diciendo a spring security correctamente que página esta autenticada.

            Aquí expongo mi código del servlet:
            UsernamePasswordAuthenticationToken userPassA = new UsernamePasswordAuthenticationToken(“usuarioAutenticado”,”passwordAutenticada”));
            ActiveDirectoryLdapAuthenticationProvider authenticationManager = new ActiveDirectoryLdapAuthenticationProvider ();
            authenticationManager.authenticate(userPassA);

            response.sendRedirect(request.getContextPath() + “/client/index.html”);
            Un saludo. Y muchas gracias por su atención.

  11. intraron dice:

    Saludos Estimado.

    Gracias por el aporte,

    Te comento que estoy tratando de incorporar S-S en mi app y tengo mil dudas.
    Mi BD es postgres y la tabla que consulto para el login es de nombre “operadores”

    Ahora con spring mvc he logrado gestionar todo por controladores y capturar los campos para cargarlo en el objeto Operador para validar el login.

    Ahora mi dura, estoy viendo en el ejemplo que colocas, que se define en el context la intersección y valida si es USER o ADMIN. Pero, Como hace S-S para saber si un usuario que esta haciendo login es ADMIN o USER?

    Sorry si estoy haciendo un pregunta obvia pero estoy nuevo con el uso de este FrameWork.

    Muchas gracias nuevamente por el aporte y tus comentarios.

    • cperez dice:

      Hola, Intraron

      El tema de los roles lo gestionas tú mismo cuando defines tu UserDetailsService, es decir, cuando recuperas de base de datos la información del usuario que está haciendo login, devuelves un objeto de tipo UserDetails. Ahí debes incluir en el campo “authorities” el rol del usuario.

      Espero haberte ayudado

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

« »