2012-03-28 12 views
7

Tengo una aplicación con seguridad de primavera instalada y funciona bien; actualmente se está quedando sin www.exampledomain.com.Seguridad de primavera de Java: ¿interceptar la URL del subdominio para iniciar sesión de forma diferente?

Ahora quiero expandir la aplicación que se queda sin subdominio. Por ejemplo, newapp.exampledomain.com.

El único problema es que para esta nueva aplicación que necesita un usuario para iniciar sesión. En la primavera es muy fácil de interceptar las direcciones URL a través de <intercept-url pattern="/Admin/*" access="ROLE_GENERAL"/>

pero ¿qué hacer cuando se quiere interceptar un subdominio de acceso? Por ejemplo, lo siguiente no funciona para mí:

<intercept-url pattern="http://newapp.exampledomain.com/*" access="ROLE_GENERAL"/> 

¿Alguna idea de cómo evitar esto?

+0

Usted está utilizando la misma aplicación web en el subdominio, no una aplicación web diferente? – Qwerky

+0

Puede sobrescribir 'FilterSecurityInterceptor' para agregar comprobaciones de subdominio, pero huele como un truco, no una solución real. Envíe su pregunta por una solución lista para usar. Además, ¿podría ser más específico sobre la configuración de los subdominios web-app/web-container? – alexkasko

+0

Yeh, usando la misma aplicación para diferentes subdominios, los diferentes subdominios representan una funcionalidad diferente para el usuario, pero el mismo servidor la maneja (por razones de costo-efectividad). En cuanto a la configuración de los subdominios del contenedor de la aplicación web, se encuentra un filtro para encontrar el subdominio invocado y luego la solicitud se reenvía a la acción relevante para esa función de dominio. Imagine free.domain.com, que todos pueden acceder y pro.domain.com, que es mucho mejor con funcionalidad adicional. –

Respuesta

2

Una opción sería escribir su propio AccessDecisionVoter que extienda RoleVoter y agregue un cheque adicional basado en el nombre de host. Algo como esto:

public class MyVoter extends RoleVoter { 
    public int vote(Authentication authentication, 
       java.lang.Object object, 
       java.util.Collection<ConfigAttribute> attributes) { 
    FilterInvocation filterInvocation = (FilterInvocation) object; 
    HttpRequest request = filterInvocation.getHttpRequest(); 
    // get subdomain from request 
    String subdomain = getSubdomain(request); 
    if ("free".equals(subdomain)) { 
     return ACCESS_GRANTED; 
    } 
    else { 
     super.vote(authentication, object, attributes); 
    } 
    } 
} 

Luego de cable hasta el elector:

<security:http auto-config="true" 
       use-expressions="true" 
       access-decision-manager-ref="accessDecisionManager"> 
... 
</security:http> 

<bean id="accessDecisionManager" 
     class="org.springframework.security.access.vote.UnanimousBased"> 
    <property name="decisionVoters"> 
     <list> 
      <bean class="com.acme.MyVoter" /> 
     </list> 
    </property> 
</bean> 

Si quería ir un paso más allá, también puede escribir su propia configuration attributes lo que permitiría quitar los controles de nombre de host codificados en el votante y hacer algo como:

<intercept-url pattern="/Admin/*" access="ROLE_GENERAL" domain="free.acme.com" /> 
+0

la etiqueta intercept-url nunca obtiene un atributo llamado "dominio", en ninguna versión de Spring-Security. Usar un votante puede ser cierto, pero esta solución nunca funcionará. – tugcem

1

En su cookie de sesión, el dominio debe establecerse explícitamente en ejmplodominio.com.

El servidor de aplicaciones es responsable de la creación de cookies de sesión (JSESSIONID) pero no de Spring Security.

Todo lo que tiene que hacer es informar al servidor de su aplicación que desea tener siempre el mismo dominio en la cookie.

Añadir a su web.xml:

<session-config> 
     <cookie-config> 
      <domain>exampledomain.com</domain> 
     </cookie-config> 
    </session-config> 
Cuestiones relacionadas