¿Es posible mencionar la autenticación básica y basada en formularios en la seguridad de Spring utilizando la configuración del espacio de nombres sin anular a la otra? Para que la aplicación pueda servir tanto a la solicitud basada en el navegador como al cliente remoto.Seguridad de primavera: cómo mencionar autenticación basada en formularios y básica
Parece que no es posible declarar tanto la autenticación básica como la de formulario mediante la configuración del espacio de nombres.
Un enlace de referencia a la comunidad de la primavera: http://forum.springsource.org/showthread.php?t=72724&highlight=form+basic+authentication
El resultado final se desea es posible, me han encontró con el mismo problema exacto y aquí está mi solución.
En cualquier momento al definir el formulario-inicio de sesión en el espacio de nombres, anulará automáticamente cualquier otro filtro de autenticación que aplique a través del espacio de nombres. Esto se hace mediante el orden de la cadena de filtros que mira FilterChainOrder.java en la seguridad de primavera para ver cómo se aplica realmente la orden a cada filtro.
Para evitar esto quitar la etiqueta http-básica del espacio de nombres a continuación, definir manualmente el grano para manejar la autenticación básica y coloca su orden antes de que el AuthenticationProcessingFilter porque este es el filtro de seguridad de la primavera que se encargará de la forma de inicio de sesión.
El resorte BasicProcessingFilter proporciona para manejar la autenticación básica es un filtro pasivo, lo que significa que si faltan las credenciales, continuará por la cadena de filtros hasta que encuentre el filtro apropiado para manejar la solicitud.
Ahora definiendo manualmente el bean BasicProcessingFilter podemos establecer el orden en que aparecerá en la cadena de filtros. A continuación se muestra un ejemplo de las declaraciones XML adicionales que tendrá que proporcionar en el xml de seguridad (primavera de Seguridad < 3.x)
<bean id="basicProcessingFilter" class="org.springframework.security.ui.basicauth.BasicProcessingFilter">
<property name="authenticationManager"><ref bean="authenticationManager"/></property>
<security:custom-filter before="AUTHENTICATION_PROCESSING_FILTER"/>
<property name="authenticationEntryPoint"><ref bean="authenticationEntryPoint"/></property>
</bean>
<bean id="authenticationEntryPoint"
class="org.springframework.security.ui.basicauth.BasicProcessingFilterEntryPoint">
<property name="realmName" value="My Realm Here"/>
</bean>
También tenga en cuenta si su referencia AuthenticationManager no se encuentra puede agregar un alias a su espacio de nombres como el de abajo
<security:authentication-manager alias="authenticationManager"/>
El resultado final es el filtro básico se aplicará como un filtro pasivo y si sus credenciales requeridas faltan continuará abajo de la cadena de filtro y el filtro de forma-login luego manejarlo.
El problema con este enfoque es que si las credenciales se ingresan correctamente, la respuesta es la página de inicio de sesión desde el filtro de inicio de sesión de formulario.
Sin embargo, parece que este problema será resuelto por la primavera en la versión 3.1 de la seguridad de primavera y este trabajo ya no será necesario.
El response by @grimesjm tiene razón. Sin embargo, si está utilizando 3.x primavera hay que adaptarse a los nombres de las clases:
<bean id="basicProcessingFilter" class="org.springframework.security.web.authentication.www.BasicAuthenticationFilter">
<property name="authenticationManager">
<ref bean="authenticationManager" />
</property>
<property name="authenticationEntryPoint">
<ref bean="authenticationEntryPoint" />
</property>
</bean>
<bean id="authenticationEntryPoint"
class="org.springframework.security.web.authentication.www.BasicAuthenticationEntryPoint">
<property name="realmName" value="Your realm here" />
</bean>
Y
<sec:http auto-config="true">
... your intercept-url here
<sec:custom-filter before="SECURITY_CONTEXT_FILTER" ref="basicProcessingFilter" />
<sec:form-login ... />
....
</sec:http>
No sé si la colocación del filtro antes de SECURITY_CONTEXT_FILTER es la mejor opción o no .
Ahora es posible con Spring Security 3.1.0
Esto es correcto, aquí hay un enlace que expandirá esta respuesta: http://stackoverflow.com/questions/3671861/two-realms-in-same-application-with-spring-security –
Creo que el objetivo es tener la API REST compatible con ambas autenticaciones dentro del mismo reino. Definir dos reinos es como definir dos guerras: funciona, pero no es ideal. – Eugen
Agregaron la posibilidad de agregar múltiples