☰

Apache "requiere usuario válido" es válido en múltiples tipos de autenticación

tag-icon • tag-icon apache-2.4 shibboleth openid
Apache "requiere usuario válido" es válido en múltiples tipos de autenticación

Nuestro Apache utiliza mod_shib_24 (SAML-SP) y mod_auth_openidc (OIDC-RP), ambos conectados a un IdP Shibboleth (actúa como SAML-IDP y OIDC-OP).

Además tenemos 2 ubicaciones protegidas, una protegida por SAML y la otra protegida por OIDC:

  ShibCompatValidUser On

  <Location "/">
    Require shib-session
    AuthType Shibboleth
    ShibRequestSetting requireSession 1
    ShibUseHeaders On
  </Location>


  <Location "/oidctest">
    Require valid-user
    AuthType openid-connect
  </Location>

Ahora viene la parte confusa:

Si accedo a algo que no sea /oidctest/, tengo que iniciar sesión usando SAML (mod_shib_24 interviene, como se esperaba), pero después de una autenticación exitosa también puedo acceder a /oidctest/ sin tener que autenticarme con OIDC.

Esto también funciona al revés. Si accedo a /oidctest/ primero (nueva ventana privada), tengo que autenticarme usando OIDC (mod_auth_openidc interviene, como se esperaba), y después de una autenticación exitosa también puedo acceder a todas las demás ubicaciones (aparte de /oidctest/).

Entonces, ¿cómo maneja Apache las directivas de usuario válido? ¿Cómo se define un "usuario válido" en Apache?

¿Es un usuario válido para todo una vez que ha iniciado sesión, sin importar el tipo de autenticación, sin importar el módulo, sin importar el protocolo?

¿O es este un comportamiento inesperado?

Respuesta1

Según tengo entendido por la wiki de Shibboleth, elShibCompatValidUser activadoconfiguración está expresamente destinada a ser compatible conrequerir usuario válidodeclaraciones.

Antes de V2.5.2, y cuando ShibCompatValidUser está desactivado (el valor predeterminado), esto es equivalente a la regla shib-session anterior. Cuando la opción ShibCompatValidUser está habilitada, esta regla se implementa de manera compatible con la regla implementada por el propio Apache y requiere que se establezca un valor REMOTE_USER no nulo para la solicitud. Esto restaura la capacidad de implementar Shibboleth junto con otros módulos y reglas. Una versión futura del SP puede eliminar la definición "especial" y dichas reglas deberían cambiarse para que dependan de shib-session.

Verhttps://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess

Para diferenciar entre módulos también puedes usar pruebas conRequerir entornopara buscar variables de entorno establecidas por el módulo. Shibboleth por defecto establece unID de sesión de ShibPor ejemplo.

Verhttps://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess

información relacionada