diff --git a/de/15.8/config/sso-saml.rst b/de/15.8/config/sso-saml.rst index 37c474a5..c1aa0245 100644 --- a/de/15.8/config/sso-saml.rst +++ b/de/15.8/config/sso-saml.rst @@ -286,10 +286,7 @@ IdPs mit wiederholten Attributnamen ----------------------------------- Wenn der IdP denselben Attributnamen auf mehrere ````-Elemente verteilt, weist |Fess| -die Assertion zurück und die Anmeldung selbst schlägt fehl. Die Prüfung der Assertion -- Signatur, -InResponseTo und Replay -- war zu diesem Zeitpunkt bereits erfolgreich; die Zurückweisung erfolgt -erst beim Lesen der Attribute. Deshalb schlägt auch eine Konfiguration fehl, die -``saml.attribute.role.name`` gar nicht setzt. +die Assertion zurück und die Anmeldung selbst schlägt fehl. Keycloak sendet standardmäßig Assertions dieser Form: Seine Rollen- und Gruppen-Mapper geben pro Wert ein eigenes ````-Element aus, solange deren Option ``single`` nicht aktiviert ist, @@ -368,14 +365,8 @@ Signatureinstellungen .. warning:: Wenn Single Logout konfiguriert ist (``saml.idp.single_logout_service.url``), setzen Sie unbedingt auch ``saml.security.want_messages_signed=true``. - Solange die Option ``false`` ist, wird für eine an ``/sso/logout`` eingehende LogoutRequest keine - Signatur verlangt. Geprüft werden lediglich das XML-Schema, ``NotOnOrAfter`` (falls vorhanden), - ``Destination`` (falls vorhanden) und die Übereinstimmung des Issuers mit ``saml.idp.entityid`` - (falls vorhanden); die NameID in der LogoutRequest wird nie mit dem angemeldeten Benutzer verglichen. - Das Issuer-Element ist im SAML-Schema optional, sodass eine LogoutRequest, die es weglässt, nie mit - der Entity-ID des IdP verglichen wird. Ein Angreifer kann daher, ohne die Entity-ID des IdP zu - kennen, eine unsignierte LogoutRequest erzeugen und die Sitzung eines authentifizierten Benutzers - beenden, indem er diesen auf die entsprechende URL lockt. + Solange die Option ``false`` ist, wird eine LogoutRequest ohne Signatur akzeptiert, sodass eine + präparierte URL die Sitzung eines authentifizierten Benutzers beenden kann. Die Auswirkung ist eine erzwungene Abmeldung (Denial of Service), keine Kontoübernahme. Verschlüsselungseinstellungen @@ -467,14 +458,6 @@ Die vom IdP zurückgegebene SAML-Antwort wird anhand der gespeicherten ID validi Eine gespeicherte ID wird verworfen, sobald dieser Zeitraum verstrichen ist. Ist die Gültigkeit abgelaufen (zum Beispiel weil die Anmeldeseite des IdP offen gelassen wurde), kann die zurückgegebene Assertion nicht zugeordnet werden, und die Anmeldung schlägt einmalig fehl. -Wird kein Wert gesetzt, werden 3600 Sekunden verwendet. -Wird ein Wert gesetzt, der sich nicht als Zahl interpretieren lässt, werden ebenfalls 3600 Sekunden verwendet, und es wird eine mit ``Invalid saml.request.id.ttl`` beginnende Warnung protokolliert. -Ein Wert von null oder kleiner würde die AuthnRequest-ID verwerfen, bevor eine Anmeldung vom IdP zurückkehren könnte; daher werden auch in diesem Fall 3600 Sekunden verwendet und eine Warnung protokolliert. - -.. note:: - Pro Sitzung werden höchstens 10 unbeantwortete AuthnRequests aufbewahrt; wird dieses Limit überschritten, werden die ältesten verworfen. - Dies ermöglicht es, Anmeldungen gleichzeitig aus mehreren Tabs zu starten, und lässt sich nicht über eine ``saml.``-Einstellung ändern. - Wird das Limit mit einem Wert von null oder weniger überschrieben, werden stattdessen 10 verwendet und eine Warnung protokolliert. Konfigurationsbeispiele ======================= @@ -544,32 +527,15 @@ Kann nach der Authentifizierung nicht zu Fess zurückkehren - Stellen Sie sicher, dass der Wert von ``saml.sp.base.url`` mit der IdP-Konfiguration übereinstimmt - Die SAML-Assertion trifft als seitenübergreifender POST vom IdP ein. Wenn ``tomcat.sameSiteCookies`` in ``tomcat_config.properties`` auf ``lax`` (Standard) steht, sendet der - Browser das Sitzungs-Cookie nicht mit. |Fess| findet dann keine passende AuthnRequest-ID und lässt - die Anmeldung an dieser Stelle einmalig fehlschlagen. Der Browser kehrt zur Anmeldeseite mit der - Meldung „SSO-Anmeldevorgang fehlgeschlagen." zurück, und im Protokoll erscheint eine Warnung, die - mit ``Received a SAML response with no matching AuthnRequest ID in the session`` beginnt. + Browser das Sitzungs-Cookie nicht mit, und die Anmeldung schlägt einmalig fehl. Setzen Sie in diesem Fall ``tomcat.sameSiteCookies = none`` (``SameSite=None`` erfordert HTTPS) - Wenn die Anmeldung am IdP zu lange gedauert hat, ist die AuthnRequest-ID nicht mehr vorhanden, - sobald die Assertion zurückkommt; die Anmeldung schlägt einmalig fehl und muss neu gestartet - werden. Welche Warnung erscheint, zeigt, was abgelaufen ist: Eine Warnung, die mit - ``Received a SAML response after the session it belongs to had expired`` beginnt, bedeutet, dass - der Servlet-Container die gesamte Sitzung verworfen hat; eine Warnung, die - ``pending AuthnRequest ID(s) of the session had expired`` enthält, bedeutet, dass die Sitzung noch - besteht und lediglich ``saml.request.id.ttl`` abgelaufen ist. Beide werden nur protokolliert, wenn - der Browser sein Sitzungs-Cookie mitgesendet hat, und genau das unterscheidet sie vom - SameSite-Fall oben + sobald die Assertion zurückkommt; die Anmeldung schlägt einmalig fehl und muss neu gestartet werden - |Fess| setzt in ``app/WEB-INF/web.xml`` kein ``session-timeout``, sodass der Standardwert des Servlet-Containers von 30 Minuten gilt; er ist kürzer als die 3600 Sekunden von - ``saml.request.id.ttl``. Die Sitzung wird also samt der darin gehaltenen AuthnRequest-ID zuerst - verworfen: Ein höherer Wert für ``saml.request.id.ttl`` allein verlängert nicht die Zeit, die - Benutzer für die Anmeldung am IdP haben. Erhöhen Sie dafür auch den Sitzungs-Timeout. Die Warnung - zu ``saml.request.id.ttl`` erscheint daher nur dort, wo die TTL kürzer als der Sitzungs-Timeout - eingestellt ist - -.. note:: - In 15.7 leitete |Fess| in derselben Situation immer wieder zum IdP weiter, sodass die Anmeldung in - einer Schleife lief. In 15.8 schlägt sie stattdessen einmalig fehl. An der Konfigurationslösung - ändert sich nichts. + ``saml.request.id.ttl``, sodass die Sitzung zuerst verworfen wird. Ein höherer Wert für + ``saml.request.id.ttl`` allein verlängert daher nicht die Zeit, die Benutzer für die Anmeldung am + IdP haben. Erhöhen Sie dafür auch den Sitzungs-Timeout Destination-Validierung schlägt hinter einem Reverse Proxy fehl ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -577,12 +543,10 @@ Destination-Validierung schlägt hinter einem Reverse Proxy fehl Wenn |Fess| hinter einem TLS-terminierenden Reverse Proxy oder Load Balancer betrieben wird, kann die Assertion-Validierung fehlschlagen, obwohl ``saml.sp.base.url`` korrekt gesetzt ist. -Die Ursache: Die SAML-Bibliothek vergleicht das Attribut ``Destination`` der Assertion mit der vom -Servlet-Container rekonstruierten Anfrage-URL und nicht mit der konfigurierten ACS-URL. Wenn der Proxy -HTTPS terminiert, sieht |Fess| eine interne Anfrage-URL wie -``http://:/sso/``, die nicht mit der vom IdP gesendeten URL -``https://fess.example.com/sso/`` übereinstimmt. ``saml.sp.base.url`` wird für diesen Vergleich nicht -herangezogen; die Einstellung allein behebt das Problem daher nicht. +Das Attribut ``Destination`` der Assertion wird mit der URL der Anfrage verglichen, so wie sie bei +|Fess| ankommt -- hinter einem TLS-terminierenden Proxy also eine interne ``http://``-URL und nicht +die externe, an die der IdP die Assertion gesendet hat. ``saml.sp.base.url`` wird für diesen +Vergleich nicht herangezogen; die Einstellung allein behebt das Problem daher nicht. Setzen Sie ``saml.debug=true``, damit der Grund ins Protokoll geschrieben wird: diff --git a/en/15.8/config/sso-saml.rst b/en/15.8/config/sso-saml.rst index 5a8d1d9f..f6778cfa 100644 --- a/en/15.8/config/sso-saml.rst +++ b/en/15.8/config/sso-saml.rst @@ -283,10 +283,7 @@ IdPs that repeat an attribute name ---------------------------------- If the IdP splits the same attribute name across several ```` elements, |Fess| refuses -the assertion and the login itself fails. Validation of the assertion -- signature, InResponseTo and -replay -- has already succeeded at that point; the refusal happens while the attributes are being -read, so a configuration that does not set ``saml.attribute.role.name`` at all fails in exactly the -same way. +the assertion and the login itself fails. Keycloak sends assertions of this shape by default: its role and group mappers emit one ```` element per value unless their ``single`` option is enabled, and every Keycloak @@ -364,13 +361,8 @@ Signature Settings .. warning:: When Single Logout is configured (``saml.idp.single_logout_service.url``), always set ``saml.security.want_messages_signed=true`` as well. - While it is ``false``, no signature is required on a LogoutRequest received at ``/sso/logout``. - The only checks performed are the XML schema, ``NotOnOrAfter`` (if present), ``Destination`` - (if present), and that the Issuer matches ``saml.idp.entityid`` (if present); the NameID in the - LogoutRequest is never compared against the logged-in user. The Issuer element is optional in the - SAML schema, so a LogoutRequest that omits it is never compared against the IdP entity ID. An - attacker, without needing to know the IdP entity ID, can therefore craft an unsigned LogoutRequest - and terminate an authenticated user's session by luring that user to the URL. + While it is ``false``, a LogoutRequest that carries no signature is accepted, so a crafted URL + can end an authenticated user's session. The impact is a forced logout (denial of service), not account takeover. Encryption Settings @@ -462,14 +454,6 @@ The SAML response returned by the IdP is validated against the recorded ID. A recorded ID is discarded once this period passes. If it expires (for example the IdP login page was left open), the returned assertion cannot be matched and the login fails once. -If no value is set, 3600 seconds is used. -If a value that cannot be parsed as a number is set, 3600 seconds is also used and a warning beginning with ``Invalid saml.request.id.ttl`` is logged. -A value of zero or less would discard the AuthnRequest ID before a login could return from the IdP, so it is likewise replaced with 3600 seconds and a warning is logged. - -.. note:: - At most 10 unanswered AuthnRequests are kept per session; when the cap is exceeded the oldest are discarded. - This exists so that logins can be started from several tabs at once, and it cannot be changed with a ``saml.`` setting. - If it is overridden with a value of zero or less, 10 is used instead and a warning is logged. Configuration Examples ====================== @@ -539,27 +523,14 @@ Cannot return to Fess after authentication - Ensure the ``saml.sp.base.url`` value matches the IdP configuration - The SAML assertion arrives as a cross-site POST from the IdP. When ``tomcat.sameSiteCookies`` in ``tomcat_config.properties`` is ``lax`` (the default), the browser does not send the session cookie - with it, so |Fess| finds no matching AuthnRequest ID and fails the login once, on the spot. The - browser returns to the login page showing "SSO login process failed.", and a warning beginning with - ``Received a SAML response with no matching AuthnRequest ID in the session`` is written to the log. - Set ``tomcat.sameSiteCookies = none`` in that case (``SameSite=None`` requires HTTPS) + with it and the login fails once. Set ``tomcat.sameSiteCookies = none`` in that case + (``SameSite=None`` requires HTTPS) - If the login took too long at the IdP, the AuthnRequest ID is no longer there when the assertion - comes back, so the login fails once and has to be started again. Which warning appears says what - ran out: one beginning with ``Received a SAML response after the session it belongs to had - expired`` means the servlet container discarded the whole session, while one containing - ``pending AuthnRequest ID(s) of the session had expired`` means the session is still alive and - only ``saml.request.id.ttl`` elapsed. Both are written only when the browser did send its session - cookie, which is what separates them from the SameSite case above + comes back, so the login fails once and has to be started again - |Fess| leaves ``session-timeout`` unset in ``app/WEB-INF/web.xml``, so the servlet container's - default of 30 minutes applies and is shorter than the 3600 seconds of ``saml.request.id.ttl``. The - session, and with it the AuthnRequest ID it holds, is discarded first, so raising - ``saml.request.id.ttl`` on its own does not give users longer to finish logging in at the IdP: - raise the session timeout as well. The ``saml.request.id.ttl`` warning is therefore only seen - where the TTL is set shorter than the session timeout - -.. note:: - In 15.7 the same situation caused |Fess| to redirect to the IdP again and again, looping the login. - 15.8 fails once instead of looping. The configuration remedy is unchanged. + default of 30 minutes applies and is shorter than the 3600 seconds of ``saml.request.id.ttl``. + Raising ``saml.request.id.ttl`` on its own therefore does not give users longer to finish logging + in at the IdP: raise the session timeout as well Destination validation fails behind a reverse proxy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -567,12 +538,10 @@ Destination validation fails behind a reverse proxy When |Fess| runs behind a TLS-terminating reverse proxy or load balancer, assertion validation can fail even though ``saml.sp.base.url`` is set correctly. -The cause is that the SAML library compares the ``Destination`` attribute of the assertion against -the request URL reconstructed by the servlet container, not against the configured ACS URL. When the -proxy terminates HTTPS, the request URL |Fess| sees is an internal one such as -``http://:/sso/``, which does not match the -``https://fess.example.com/sso/`` sent by the IdP. ``saml.sp.base.url`` is not used for this -comparison, so setting it alone does not fix the problem. +The ``Destination`` attribute of the assertion is compared against the URL of the request as it +reaches |Fess|, which behind a TLS-terminating proxy is an internal ``http://`` URL rather than the +external one the IdP sent the assertion to. ``saml.sp.base.url`` is not used for this comparison, +so setting it alone does not fix the problem. Set ``saml.debug=true`` to have the reason written to the log: diff --git a/es/15.8/config/sso-saml.rst b/es/15.8/config/sso-saml.rst index cde8c6ef..23d03ddb 100644 --- a/es/15.8/config/sso-saml.rst +++ b/es/15.8/config/sso-saml.rst @@ -286,10 +286,7 @@ IdP que repiten un nombre de atributo ------------------------------------- Si el IdP reparte el mismo nombre de atributo entre varios elementos ````, |Fess| -rechaza la aserción y el inicio de sesión falla. La validación de la aserción -- firma, InResponseTo -y repetición -- ya se ha completado correctamente en ese punto; el rechazo ocurre al leer los -atributos, por lo que una configuración que no establece ``saml.attribute.role.name`` falla -exactamente igual. +rechaza la aserción y el inicio de sesión falla. Keycloak envía aserciones con esta forma de manera predeterminada: sus mapeadores de roles y grupos emiten un elemento ```` por cada valor salvo que se active su opción ``single``, y toda @@ -368,14 +365,8 @@ Configuración de firma .. warning:: Cuando se configura el cierre de sesión único (``saml.idp.single_logout_service.url``), establezca siempre también ``saml.security.want_messages_signed=true``. - Mientras sea ``false``, no se exige ninguna firma en una LogoutRequest recibida en ``/sso/logout``. - Las únicas comprobaciones que se realizan son el esquema XML, ``NotOnOrAfter`` (si está presente), - ``Destination`` (si está presente) y que el Issuer coincida con ``saml.idp.entityid`` (si está - presente); el NameID de la LogoutRequest nunca se compara con el usuario que ha iniciado sesión. - El elemento Issuer es opcional en el esquema SAML, por lo que una LogoutRequest que lo omita nunca - se compara con el identificador de entidad del IdP. Por tanto, un atacante, sin necesidad de conocer - el identificador de entidad del IdP, puede crear una LogoutRequest sin firmar y terminar la sesión - de un usuario autenticado atrayéndolo a esa URL. + Mientras sea ``false``, se acepta una LogoutRequest sin firma, por lo que una URL manipulada puede + terminar la sesión de un usuario autenticado. El impacto es un cierre de sesión forzado (denegación de servicio), no una apropiación de la cuenta. Configuración de cifrado @@ -467,14 +458,6 @@ La respuesta SAML devuelta por el IdP se valida frente al identificador registra El identificador registrado se descarta una vez transcurrido este periodo. Si expira (por ejemplo, porque se dejó abierta la página de inicio de sesión del IdP), la aserción devuelta no puede emparejarse y el inicio de sesión falla una sola vez. -Si no se establece ningún valor, se usan 3600 segundos. -Si se establece un valor que no puede interpretarse como un número, también se usan 3600 segundos y se registra una advertencia que comienza por ``Invalid saml.request.id.ttl``. -Un valor igual o menor que cero descartaría el identificador de la AuthnRequest antes de que el inicio de sesión pudiera regresar del IdP, por lo que también en ese caso se usan 3600 segundos y se registra una advertencia. - -.. note:: - Como máximo se conservan 10 AuthnRequest sin respuesta por sesión; al superar ese límite, se descartan las más antiguas. - Esto existe para permitir iniciar sesiones desde varias pestañas a la vez, y no se puede cambiar con ningún ajuste ``saml.``. - Si el límite se sobrescribe con un valor de cero o menos, se usan 10 en su lugar y se registra una advertencia. Ejemplos de configuración ========================= @@ -544,32 +527,16 @@ No se puede regresar a Fess después de la autenticación - Asegúrese de que el valor de ``saml.sp.base.url`` coincida con la configuración del IdP - La aserción SAML llega como un POST entre sitios desde el IdP. Cuando ``tomcat.sameSiteCookies`` en ``tomcat_config.properties`` es ``lax`` (el valor predeterminado), el - navegador no envía la cookie de sesión con ella, por lo que |Fess| no encuentra ninguna AuthnRequest - con la que emparejar y el inicio de sesión falla una sola vez, en ese momento. El navegador vuelve a - la página de inicio de sesión mostrando «Error en el proceso de inicio de sesión SSO.» y en el - registro se escribe una advertencia que empieza por - ``Received a SAML response with no matching AuthnRequest ID in the session``. + navegador no envía la cookie de sesión con ella y el inicio de sesión falla una sola vez. En ese caso, configure ``tomcat.sameSiteCookies = none`` (``SameSite=None`` requiere HTTPS) - Si el inicio de sesión tardó demasiado en el IdP, el identificador de AuthnRequest ya no está disponible cuando llega la aserción, por lo que el inicio de sesión falla una sola vez y hay que - empezarlo de nuevo. La advertencia que aparece indica qué caducó: una que empieza por - ``Received a SAML response after the session it belongs to had expired`` significa que el - contenedor de servlets descartó la sesión entera, mientras que una que contiene - ``pending AuthnRequest ID(s) of the session had expired`` significa que la sesión sigue activa y - que solo expiró ``saml.request.id.ttl``. Ambas se registran únicamente cuando el navegador sí - envió su cookie de sesión, que es lo que las distingue del caso SameSite anterior + empezarlo de nuevo - |Fess| no define ``session-timeout`` en ``app/WEB-INF/web.xml``, por lo que se aplica el valor predeterminado del contenedor de servlets, 30 minutos, más corto que los 3600 segundos de - ``saml.request.id.ttl``. La sesión, y con ella el identificador de AuthnRequest que guarda, se - descarta antes: aumentar solo ``saml.request.id.ttl`` no da a los usuarios más tiempo para - completar el inicio de sesión en el IdP, así que amplíe también el tiempo de espera de la sesión. - Por eso la advertencia de ``saml.request.id.ttl`` solo aparece donde el TTL se ha configurado por - debajo del tiempo de espera de la sesión - -.. note:: - En 15.7, la misma situación hacía que |Fess| redirigiera una y otra vez al IdP, dejando el inicio de - sesión en un bucle. En 15.8 falla una sola vez en lugar de entrar en bucle. La solución de - configuración no cambia. + ``saml.request.id.ttl``, y la sesión se descarta antes. Aumentar solo ``saml.request.id.ttl`` no da + a los usuarios más tiempo para completar el inicio de sesión en el IdP, así que amplíe también el + tiempo de espera de la sesión La validación de Destination falla detrás de un proxy inverso ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -577,12 +544,10 @@ La validación de Destination falla detrás de un proxy inverso Cuando |Fess| se ejecuta detrás de un proxy inverso o balanceador de carga que termina TLS, la validación de la aserción puede fallar aunque ``saml.sp.base.url`` esté configurado correctamente. -La causa es que la biblioteca SAML compara el atributo ``Destination`` de la aserción con la URL de la -solicitud reconstruida por el contenedor de servlets, y no con la URL ACS configurada. Cuando el proxy -termina HTTPS, la URL de solicitud que ve |Fess| es interna, como -``http://:/sso/``, y no coincide con la -``https://fess.example.com/sso/`` enviada por el IdP. ``saml.sp.base.url`` no se utiliza para esta -comparación, por lo que configurarlo por sí solo no resuelve el problema. +El atributo ``Destination`` de la aserción se compara con la URL de la solicitud tal como llega a +|Fess|, que detrás de un proxy que termina TLS es una URL interna ``http://`` y no la externa a la +que el IdP envió la aserción. ``saml.sp.base.url`` no se utiliza para esta comparación, por lo que +configurarlo por sí solo no resuelve el problema. Configure ``saml.debug=true`` para que el motivo se escriba en el registro: diff --git a/fr/15.8/config/sso-saml.rst b/fr/15.8/config/sso-saml.rst index 0f4e6b14..7409f4ab 100644 --- a/fr/15.8/config/sso-saml.rst +++ b/fr/15.8/config/sso-saml.rst @@ -287,9 +287,7 @@ IdP qui répètent un nom d'attribut ---------------------------------- Si l'IdP répartit le même nom d'attribut sur plusieurs éléments ````, |Fess| refuse -l'assertion et la connexion échoue. La validation de l'assertion -- signature, InResponseTo et rejeu --- a déjà réussi à ce stade ; le refus intervient lors de la lecture des attributs, si bien qu'une -configuration qui ne définit pas ``saml.attribute.role.name`` échoue exactement de la même façon. +l'assertion et la connexion échoue. Keycloak envoie par défaut des assertions de cette forme : ses mappeurs de rôles et de groupes émettent un élément ```` par valeur tant que leur option ``single`` n'est pas activée, et @@ -368,14 +366,8 @@ Paramètres de signature .. warning:: Lorsque la déconnexion unique est configurée (``saml.idp.single_logout_service.url``), définissez impérativement aussi ``saml.security.want_messages_signed=true``. - Tant que ce paramètre vaut ``false``, aucune signature n'est exigée sur une LogoutRequest reçue sur - ``/sso/logout``. Les seules vérifications effectuées sont le schéma XML, ``NotOnOrAfter`` (s'il est - présent), ``Destination`` (s'il est présent) et la correspondance de l'Issuer avec - ``saml.idp.entityid`` (s'il est présent) ; le NameID de la LogoutRequest n'est jamais comparé à - l'utilisateur connecté. L'élément Issuer est optionnel dans le schéma SAML, si bien qu'une - LogoutRequest qui l'omet n'est jamais comparée à l'identifiant d'entité de l'IdP. Un attaquant peut - donc, sans avoir besoin de connaître l'identifiant d'entité de l'IdP, forger une LogoutRequest non - signée et mettre fin à la session d'un utilisateur authentifié en l'attirant vers cette URL. + Tant que ce paramètre vaut ``false``, une LogoutRequest sans signature est acceptée : une URL + forgée peut donc mettre fin à la session d'un utilisateur authentifié. L'impact est une déconnexion forcée (déni de service), et non une prise de contrôle du compte. Paramètres de chiffrement @@ -467,14 +459,6 @@ La réponse SAML renvoyée par l'IdP est validée par rapport à l'identifiant e L'identifiant enregistré est écarté une fois ce délai écoulé. S'il expire (par exemple parce que la page de connexion de l'IdP est restée ouverte), l'assertion renvoyée ne peut pas être associée et la connexion échoue une seule fois. -Si aucune valeur n'est définie, 3600 secondes sont utilisées. -Si une valeur qui ne peut pas être interprétée comme un nombre est définie, 3600 secondes sont également utilisées et un avertissement commençant par ``Invalid saml.request.id.ttl`` est consigné. -Une valeur nulle ou négative écarterait l'identifiant de l'AuthnRequest avant qu'une connexion puisse revenir de l'IdP ; dans ce cas également, 3600 secondes sont utilisées et un avertissement est consigné. - -.. note:: - Au maximum 10 AuthnRequest restées sans réponse sont conservées par session ; lorsque cette limite est dépassée, les plus anciennes sont écartées. - Cela permet de démarrer des connexions depuis plusieurs onglets à la fois, et ne peut pas être modifié par un paramètre ``saml.``. - Si la limite est remplacée par une valeur inférieure ou égale à zéro, la valeur 10 est utilisée à la place et un avertissement est consigné. Exemples de configuration ========================= @@ -544,32 +528,15 @@ Impossible de retourner à Fess après l'authentification - Assurez-vous que la valeur de ``saml.sp.base.url`` correspond à la configuration de l'IdP - L'assertion SAML arrive sous forme de POST intersite depuis l'IdP. Lorsque ``tomcat.sameSiteCookies`` dans ``tomcat_config.properties`` vaut ``lax`` (la valeur par défaut), - le navigateur n'envoie pas le cookie de session avec cette requête ; |Fess| ne trouve alors aucun - identifiant d'AuthnRequest correspondant et fait échouer la connexion une seule fois, sur place. Le - navigateur revient à la page de connexion en affichant « Le processus de connexion SSO a échoué. », - et un avertissement commençant par - ``Received a SAML response with no matching AuthnRequest ID in the session`` est écrit dans le - journal. Dans ce cas, définissez ``tomcat.sameSiteCookies = none`` (``SameSite=None`` nécessite HTTPS) + le navigateur n'envoie pas le cookie de session avec cette requête et la connexion échoue une seule + fois. Dans ce cas, définissez ``tomcat.sameSiteCookies = none`` (``SameSite=None`` nécessite HTTPS) - Si la connexion a pris trop de temps chez l'IdP, l'identifiant d'AuthnRequest n'est plus présent - lorsque l'assertion revient : la connexion échoue une seule fois et doit être recommencée. - L'avertissement consigné indique ce qui a expiré : celui qui commence par - ``Received a SAML response after the session it belongs to had expired`` signifie que le conteneur - de servlets a supprimé la session entière, tandis que celui qui contient - ``pending AuthnRequest ID(s) of the session had expired`` signifie que la session est toujours - active et que seul ``saml.request.id.ttl`` a expiré. Les deux ne sont écrits que si le navigateur - a bien envoyé son cookie de session, ce qui les distingue du cas SameSite ci-dessus + lorsque l'assertion revient : la connexion échoue une seule fois et doit être recommencée - |Fess| ne définit pas ``session-timeout`` dans ``app/WEB-INF/web.xml`` ; la valeur par défaut du conteneur de servlets, 30 minutes, s'applique donc, et elle est plus courte que les 3600 secondes - de ``saml.request.id.ttl``. La session, et avec elle l'identifiant d'AuthnRequest qu'elle - conserve, est écartée en premier : augmenter uniquement ``saml.request.id.ttl`` ne laisse pas plus - de temps aux utilisateurs pour terminer la connexion chez l'IdP, il faut aussi allonger le délai - d'expiration de session. L'avertissement relatif à ``saml.request.id.ttl`` n'apparaît donc que - lorsque la TTL est réglée en dessous de ce délai - -.. note:: - En 15.7, la même situation faisait rediriger |Fess| encore et encore vers l'IdP, mettant la connexion - en boucle. En 15.8, elle échoue une seule fois au lieu de boucler. La solution de configuration reste - la même. + de ``saml.request.id.ttl``, si bien que la session est écartée en premier. Augmenter uniquement + ``saml.request.id.ttl`` ne laisse pas plus de temps aux utilisateurs pour terminer la connexion + chez l'IdP : allongez aussi le délai d'expiration de session La validation de Destination échoue derrière un proxy inverse ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -577,12 +544,10 @@ La validation de Destination échoue derrière un proxy inverse Lorsque |Fess| s'exécute derrière un proxy inverse ou un répartiteur de charge qui termine TLS, la validation de l'assertion peut échouer même si ``saml.sp.base.url`` est correctement défini. -La cause est que la bibliothèque SAML compare l'attribut ``Destination`` de l'assertion à l'URL de -requête reconstruite par le conteneur de servlets, et non à l'URL ACS configurée. Lorsque le proxy -termine HTTPS, l'URL de requête vue par |Fess| est une URL interne telle que -``http://:/sso/``, qui ne correspond pas à -``https://fess.example.com/sso/`` envoyée par l'IdP. ``saml.sp.base.url`` n'intervient pas dans cette -comparaison ; le définir seul ne résout donc pas le problème. +L'attribut ``Destination`` de l'assertion est comparé à l'URL de la requête telle qu'elle parvient +à |Fess| : derrière un proxy qui termine TLS, il s'agit d'une URL interne en ``http://`` et non de +l'URL externe à laquelle l'IdP a envoyé l'assertion. ``saml.sp.base.url`` n'intervient pas dans +cette comparaison ; le définir seul ne résout donc pas le problème. Définissez ``saml.debug=true`` pour que la raison soit écrite dans le journal : diff --git a/ja/15.8/config/sso-saml.rst b/ja/15.8/config/sso-saml.rst index 5016b950..a1bc209a 100644 --- a/ja/15.8/config/sso-saml.rst +++ b/ja/15.8/config/sso-saml.rst @@ -285,9 +285,7 @@ SAMLアサーションから取得したユーザー属性を、|Fess| のグル ------------------- IdPが同じ属性名を複数の ```` 要素に分けて送信した場合、|Fess| はそのアサーションを -受け付けず、ログイン自体が失敗します。アサーションの検証（署名・InResponseTo・リプレイ）は -この時点で成功しており、拒否されるのは属性を読み取る段階です。そのため -``saml.attribute.role.name`` を設定していない構成でも同じように失敗します。 +受け付けず、ログイン自体が失敗します。 Keycloakは既定でこの形式のアサーションを送信します。ロールマッパーとグループマッパーは ``single`` オプションを有効にしない限り値ごとに別々の ```` 要素を出力し、 @@ -364,13 +362,8 @@ Keycloakのアカウントは既定で複数のレルムロールを持つため .. warning:: シングルログアウト（``saml.idp.single_logout_service.url``）を設定する場合は、 ``saml.security.want_messages_signed=true`` を必ず併せて設定してください。 - ``false`` のままでは、``/sso/logout`` が受け取るLogoutRequestに署名が要求されません。 - 検証されるのはXMLスキーマ、``NotOnOrAfter``（存在する場合）、``Destination``（存在する場合）、 - および Issuer が ``saml.idp.entityid`` と一致すること（存在する場合）だけで、 - LogoutRequest内のNameIDがログイン中のユーザーと一致するかは検査されません。 - Issuer要素はSAMLのスキーマ上は省略可能であり、省略されたLogoutRequestではIdPのEntity IDとの - 照合そのものが行われません。このため攻撃者はIdPのEntity IDを知らなくても、署名のないLogoutRequestを作成し、 - そのURLをユーザーに踏ませることで認証済みセッションを終了させられます。 + ``false`` のままでは署名のないLogoutRequestが受理されるため、 + 細工されたURLを踏ませることで認証済みセッションを終了させられます。 影響は強制ログアウト（サービス妨害）であり、アカウントの乗っ取りではありません。 暗号化の設定 @@ -468,15 +461,6 @@ IdPから返されたSAMLレスポンスは、記録されたIDと対応付け 記録されたIDは、この期間を過ぎると破棄されます。IdPのログイン画面を開いたまま放置するなどして 有効期限を過ぎた場合、戻ってきたアサーションは対応付けられず、その場で1回だけログインに失敗します。 -値を指定しない場合は3600秒が使われます。数値として解釈できない値を指定した場合も3600秒が使われ、 -``Invalid saml.request.id.ttl`` で始まる警告が出力されます。 -0以下の値を指定した場合も、IdPからログインが戻ってくる前にAuthnRequestのIDが破棄されてしまうため、 -同様に3600秒が使われ、警告が出力されます。 - -.. note:: - 1つのセッションで保持できる応答待ちのAuthnRequestは最大10件で、上限を超えると古いものから破棄されます。 - これは複数のタブから同時にログインを開始できるようにするためのもので、``saml.`` で始まる設定では変更できません。 - 上限に0以下の値を指定して上書きした場合は、代わりに10が使われ、警告が出力されます。 設定例 ====== @@ -546,29 +530,14 @@ IdPから返されたSAMLレスポンスは、記録されたIDと対応付け - ``saml.sp.base.url`` の値がIdP側の設定と一致しているか確認してください - IdPからのSAMLアサーションはクロスサイトのPOSTで送信されます。``tomcat_config.properties`` の ``tomcat.sameSiteCookies`` が ``lax``（既定値）の場合、ブラウザはセッションCookieを送信しないため、 - |Fess| は対応するAuthnRequestのIDを見つけられず、その場で1回だけログインに失敗します。 - ブラウザはログイン画面に戻り「SSOログイン処理に失敗しました。」が表示され、ログには - ``Received a SAML response with no matching AuthnRequest ID in the session`` - で始まる警告が出力されます。この場合は ``tomcat.sameSiteCookies = none`` を設定してください + その場で1回だけログインに失敗します。この場合は ``tomcat.sameSiteCookies = none`` を設定してください （``SameSite=None`` はHTTPSが必須です） - IdPでのログインに時間がかかった場合、アサーションが戻ってきた時点でAuthnRequestのIDは残っていないため、 - その場で1回だけログインに失敗します。この場合はログインをやり直してください。 - 何が期限切れになったのかは、出力される警告で見分けられます。 - ``Received a SAML response after the session it belongs to had expired`` で始まる警告は、 - サーブレットコンテナがセッションごと破棄したことを表します。 - ``pending AuthnRequest ID(s) of the session had expired`` を含む警告は、セッションは生きたままで - ``saml.request.id.ttl`` だけが経過したことを表します。どちらもブラウザがセッションCookieを - 送信できている場合にのみ出力され、その点が上記のSameSiteのケースとの違いです + その場で1回だけログインに失敗します。この場合はログインをやり直してください - |Fess| は ``app/WEB-INF/web.xml`` で ``session-timeout`` を指定していないため、 サーブレットコンテナの既定値である30分が適用されます。これは ``saml.request.id.ttl`` の3600秒より短く、 - セッションが先に破棄されて、保持していたAuthnRequestのIDも一緒に失われます。 - このため ``saml.request.id.ttl`` だけを大きくしても、IdPでログインを完了するまでの猶予は延びません。 - 猶予を延ばしたい場合は、セッションタイムアウトも合わせて延長してください。 - ``saml.request.id.ttl`` の警告が出力されるのは、TTLをセッションタイムアウトより短く設定した場合だけです - -.. note:: - 15.7 では同じ状況でIdPへの再リダイレクトが繰り返され、ログインがループしていました。 - 15.8 ではループせずに1回で失敗するよう変更されています。設定の対処方法は変わりません。 + セッションが先に破棄されます。このため ``saml.request.id.ttl`` だけを大きくしても猶予は延びません。 + 猶予を延ばしたい場合は、セッションタイムアウトも合わせて延長してください リバースプロキシ経由でDestinationの検証に失敗する ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -576,10 +545,8 @@ IdPから返されたSAMLレスポンスは、記録されたIDと対応付け TLSを終端するリバースプロキシやロードバランサーの背後に |Fess| を配置すると、 ``saml.sp.base.url`` を正しく設定していてもアサーションの検証に失敗することがあります。 -原因は、SAMLライブラリがアサーションの ``Destination`` 属性を、設定されたACS URLではなく -サーブレットコンテナが組み立てたリクエストURLと比較するためです。プロキシがHTTPSを終端すると、 -|Fess| が認識するリクエストURLは ``http://<内部ホスト名>:<内部ポート>/sso/`` のような内部向けの値になり、 -IdPが送ってきた ``https://fess.example.com/sso/`` と一致しません。 +アサーションの ``Destination`` 属性は、|Fess| に届いた時点のリクエストURLと比較されます。 +TLSを終端するプロキシの背後では、これはIdPがアサーションを送った外部URLではなく内部の ``http://`` のURLです。 ``saml.sp.base.url`` はこの比較には使われないため、この設定だけでは解決しません。 ``saml.debug=true`` を設定すると、ログに以下のような理由が出力されます。 diff --git a/ko/15.8/config/sso-saml.rst b/ko/15.8/config/sso-saml.rst index 9c505b83..287aa854 100644 --- a/ko/15.8/config/sso-saml.rst +++ b/ko/15.8/config/sso-saml.rst @@ -284,9 +284,7 @@ SAML 어서션에서 취득한 사용자 속성을 |Fess| 의 그룹이나 역 ------------------------ IdP가 동일한 속성 이름을 여러 ```` 요소로 나누어 보내면 |Fess| 는 해당 어서션을 -거부하며 로그인 자체가 실패합니다. 어서션 검증(서명, InResponseTo, 재전송)은 이 시점에서 이미 -성공한 상태이며, 거부는 속성을 읽는 단계에서 발생합니다. 따라서 ``saml.attribute.role.name`` 을 -설정하지 않은 구성에서도 동일하게 실패합니다. +거부하며 로그인 자체가 실패합니다. Keycloak은 기본적으로 이러한 형태의 어서션을 보냅니다. 역할 매퍼와 그룹 매퍼는 ``single`` 옵션을 활성화하지 않는 한 값마다 별도의 ```` 요소를 출력하며, Keycloak 계정은 @@ -363,13 +361,8 @@ Keycloak은 기본적으로 이러한 형태의 어서션을 보냅니다. 역 .. warning:: 싱글 로그아웃（``saml.idp.single_logout_service.url``）을 설정하는 경우에는 ``saml.security.want_messages_signed=true`` 도 반드시 함께 설정하십시오. - ``false`` 인 상태에서는 ``/sso/logout`` 이 수신하는 LogoutRequest에 서명이 요구되지 않습니다. - 검증되는 것은 XML 스키마, ``NotOnOrAfter``（존재하는 경우）, ``Destination``（존재하는 경우）, - 그리고 Issuer가 ``saml.idp.entityid`` 와 일치하는지（존재하는 경우）뿐이며, - LogoutRequest 안의 NameID가 로그인 중인 사용자와 일치하는지는 검사하지 않습니다. - Issuer 요소는 SAML 스키마상 생략 가능하며, 생략된 LogoutRequest에서는 IdP의 Entity ID와의 - 대조 자체가 이루어지지 않습니다. 이 때문에 공격자는 IdP의 Entity ID를 몰라도 서명 없는 - LogoutRequest를 만들어, 해당 URL로 사용자를 유도함으로써 인증된 세션을 종료시킬 수 있습니다. + ``false`` 인 상태에서는 서명이 없는 LogoutRequest가 수락되므로, 조작된 URL로 인증된 사용자의 + 세션을 종료시킬 수 있습니다. 영향은 강제 로그아웃（서비스 거부）이며, 계정 탈취는 아닙니다. 암호화 설정 @@ -467,14 +460,6 @@ IdP에서 반환된 SAML 응답은 기록된 ID와 대응시켜 검증됩니다. 기록된 ID는 이 기간이 지나면 폐기됩니다. IdP 로그인 화면을 열어둔 채로 방치하는 등의 이유로 유효 기간이 지나면 반환된 어서션을 대응시킬 수 없어 그 자리에서 한 번만 로그인에 실패합니다. -값을 지정하지 않으면 3600초가 사용됩니다. -숫자로 해석할 수 없는 값을 지정한 경우에도 3600초가 사용되며, ``Invalid saml.request.id.ttl`` 로 시작하는 경고가 출력됩니다. -0 이하의 값을 지정한 경우에도 IdP로부터 로그인이 돌아오기 전에 AuthnRequest의 ID가 폐기되어 버리므로, 마찬가지로 3600초가 사용되며, 경고가 출력됩니다. - -.. note:: - 하나의 세션에서 보관할 수 있는 응답 대기 중인 AuthnRequest는 최대 10건이며, 상한을 초과하면 오래된 것부터 폐기됩니다. - 이는 여러 탭에서 동시에 로그인을 시작할 수 있도록 하기 위한 것으로, ``saml.`` 로 시작하는 설정으로는 변경할 수 없습니다. - 상한을 0 이하의 값으로 덮어쓴 경우에는 대신 10이 사용되며 경고가 출력됩니다. 설정 예 ======= @@ -544,28 +529,14 @@ IdP 로그인 화면을 열어둔 채로 방치하는 등의 이유로 유효 - ``saml.sp.base.url`` 의 값이 IdP 측의 설정과 일치하는지 확인하십시오 - SAML 어설션은 IdP에서 교차 사이트 POST로 전송됩니다. ``tomcat_config.properties`` 의 ``tomcat.sameSiteCookies`` 가 ``lax`` (기본값)인 경우 브라우저가 세션 쿠키를 함께 보내지 않으므로 - |Fess| 는 대응하는 AuthnRequest의 ID를 찾지 못하고 그 자리에서 한 번만 로그인에 실패합니다. - 브라우저는 로그인 화면으로 돌아가 「SSO 로그인 프로세스에 실패했습니다.」가 표시되고, 로그에는 - ``Received a SAML response with no matching AuthnRequest ID in the session`` - 으로 시작하는 경고가 출력됩니다. 이 경우 + 그 자리에서 한 번만 로그인에 실패합니다. 이 경우 ``tomcat.sameSiteCookies = none`` 을 설정하십시오 (``SameSite=None`` 은 HTTPS가 필요합니다) - IdP에서 로그인에 시간이 오래 걸리면 어설션이 돌아온 시점에 AuthnRequest의 ID가 남아 있지 않으므로 - 그 자리에서 한 번만 로그인에 실패합니다. 이 경우에는 로그인을 다시 시작하십시오. - 무엇이 만료되었는지는 출력되는 경고로 구분할 수 있습니다. - ``Received a SAML response after the session it belongs to had expired`` 로 시작하는 경고는 - 서블릿 컨테이너가 세션 자체를 폐기했음을 뜻합니다. - ``pending AuthnRequest ID(s) of the session had expired`` 를 포함하는 경고는 세션은 살아 있고 - ``saml.request.id.ttl`` 만 경과했음을 뜻합니다. 두 경고 모두 브라우저가 세션 쿠키를 보낸 경우에만 - 출력되며, 이 점이 위의 SameSite 사례와 다릅니다 + 그 자리에서 한 번만 로그인에 실패합니다. 이 경우에는 로그인을 다시 시작하십시오 - |Fess| 는 ``app/WEB-INF/web.xml`` 에 ``session-timeout`` 을 지정하지 않으므로 서블릿 컨테이너의 - 기본값인 30분이 적용됩니다. 이는 ``saml.request.id.ttl`` 의 3600초보다 짧아, 세션이 먼저 폐기되면서 - 세션이 보관하던 AuthnRequest의 ID도 함께 사라집니다. 따라서 ``saml.request.id.ttl`` 만 늘려도 - 사용자가 IdP에서 로그인을 마칠 수 있는 시간은 늘어나지 않으므로, 세션 타임아웃도 함께 늘리십시오. - ``saml.request.id.ttl`` 경고는 TTL을 세션 타임아웃보다 짧게 설정한 경우에만 출력됩니다 - -.. note:: - 15.7에서는 같은 상황에서 IdP로의 재리다이렉트가 반복되어 로그인이 루프에 빠졌습니다. - 15.8에서는 루프 없이 한 번만 실패하도록 변경되었습니다. 설정으로 대처하는 방법은 동일합니다. + 기본값인 30분이 적용됩니다. 이는 ``saml.request.id.ttl`` 의 3600초보다 짧아 세션이 먼저 폐기됩니다. + 따라서 ``saml.request.id.ttl`` 만 늘려도 사용자가 IdP에서 로그인을 마칠 수 있는 시간은 늘어나지 + 않으므로, 세션 타임아웃도 함께 늘리십시오 리버스 프록시 환경에서 Destination 검증에 실패함 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -573,10 +544,8 @@ IdP 로그인 화면을 열어둔 채로 방치하는 등의 이유로 유효 TLS를 종단하는 리버스 프록시나 로드 밸런서 뒤에 |Fess| 를 배치하면, ``saml.sp.base.url`` 을 올바르게 설정했더라도 어설션 검증에 실패할 수 있습니다. -원인은 SAML 라이브러리가 어설션의 ``Destination`` 속성을 설정된 ACS URL이 아니라 -서블릿 컨테이너가 조립한 요청 URL과 비교하기 때문입니다. 프록시가 HTTPS를 종단하면 -|Fess| 가 인식하는 요청 URL은 ``http://<내부-호스트명>:<내부-포트>/sso/`` 와 같은 내부용 값이 되어, -IdP가 보낸 ``https://fess.example.com/sso/`` 와 일치하지 않습니다. +어설션의 ``Destination`` 속성은 |Fess| 에 도달한 시점의 요청 URL과 비교됩니다. +TLS를 종단하는 프록시 뒤에서는 이 값이 IdP가 어설션을 보낸 외부 URL이 아니라 내부 ``http://`` URL입니다. ``saml.sp.base.url`` 은 이 비교에 사용되지 않으므로 이 설정만으로는 해결되지 않습니다. ``saml.debug=true`` 를 설정하면 로그에 다음과 같은 이유가 출력됩니다. diff --git a/zh-cn/15.8/config/sso-saml.rst b/zh-cn/15.8/config/sso-saml.rst index 94df107f..361b5e52 100644 --- a/zh-cn/15.8/config/sso-saml.rst +++ b/zh-cn/15.8/config/sso-saml.rst @@ -281,8 +281,7 @@ IdP侧配置 ---------------- 如果 IdP 将同一个属性名拆分到多个 ```` 元素中发送，|Fess|\ 会拒绝该断言，登录本身 -随之失败。此时断言的校验（签名、InResponseTo 与重放检查）其实已经通过，拒绝发生在读取属性的 -阶段，因此即使是没有设置 ``saml.attribute.role.name`` 的配置也会同样失败。 +随之失败。 Keycloak 默认发送这种形式的断言：除非启用其角色映射器和组映射器的 ``single`` 选项，否则每个值 都会输出为独立的 ```` 元素，而每个 Keycloak 账户默认都带有多个领域角色。 @@ -356,12 +355,7 @@ Keycloak 默认发送这种形式的断言：除非启用其角色映射器和 .. warning:: 配置单点登出（``saml.idp.single_logout_service.url``）时，请务必同时设置\ ``saml.security.want_messages_signed=true``\ 。 - 若保持为\ ``false``\ ，则不会对\ ``/sso/logout``\ 收到的LogoutRequest要求签名。 - 此时仅校验XML架构、``NotOnOrAfter``\ （若存在）、``Destination``\ （若存在）以及Issuer是否与\ - ``saml.idp.entityid``\ 一致（若存在）；LogoutRequest中的NameID从不与已登录用户进行比对。 - Issuer元素在SAML架构中是可选的，省略该元素的LogoutRequest从不会与IdP的实体ID进行比对。 - 因此，攻击者无需知晓IdP的实体ID，即可构造未签名的LogoutRequest， - 诱导用户访问该URL，从而终止已认证用户的会话。 + 若保持为\ ``false``\ ，则会接受未签名的LogoutRequest，攻击者可诱导用户访问构造的URL，从而终止其已认证会话。 其影响是强制登出（拒绝服务），而不是账户接管。 加密设置 @@ -453,14 +447,6 @@ IdP返回的SAML响应会根据记录的ID进行校验。 记录的ID在超过该时长后会被丢弃。 如果超出有效期（例如IdP登录页面一直处于打开状态未处理），返回的断言将无法匹配，登录会当场失败一次。 -如果未设置该值，将使用3600秒。 -如果设置的值无法解析为数字，同样会使用3600秒，并在日志中输出以\ ``Invalid saml.request.id.ttl``\ 开头的警告。 -如果设置的值小于或等于0，将会在登录从IdP返回之前就丢弃AuthnRequest的ID，因此同样会使用3600秒，并在日志中输出警告。 - -.. note:: - 每个会话最多保留10个未收到响应的AuthnRequest，超出上限后将丢弃最旧的。 - 这是为了支持同时从多个标签页发起登录，且无法通过\ ``saml.``\ 开头的设置进行更改。 - 如果将上限覆盖为0或更小的值，则会改用10并输出警告。 配置示例 ======== @@ -530,24 +516,12 @@ IdP返回的SAML响应会根据记录的ID进行校验。 - 确保\ ``saml.sp.base.url``\ 的值与IdP配置匹配 - SAML断言以来自IdP的跨站POST方式发送。 当\ ``tomcat_config.properties``\ 中的\ ``tomcat.sameSiteCookies``\ 为\ ``lax``\ （默认值）时， - 浏览器不会随该请求发送会话Cookie，因此 |Fess| 找不到可匹配的AuthnRequest ID，当场只失败一次。 - 浏览器会返回登录页面并显示"SSO登录处理失败。"，日志中会输出以\ - ``Received a SAML response with no matching AuthnRequest ID in the session``\ 开头的警告。 + 浏览器不会随该请求发送会话Cookie，登录会当场只失败一次。 此时请设置\ ``tomcat.sameSiteCookies = none``\ （``SameSite=None``\ 需要HTTPS） -- 如果在IdP上的登录耗时过长，断言返回时AuthnRequest ID已经不存在，登录会当场只失败一次，需要重新开始登录。 - 输出哪条警告可以判断是什么超时了：以\ - ``Received a SAML response after the session it belongs to had expired``\ 开头的警告表示 - Servlet容器已经丢弃了整个会话；包含\ ``pending AuthnRequest ID(s) of the session had expired``\ - 的警告表示会话仍然存在，只是\ ``saml.request.id.ttl``\ 超时。 - 这两条警告都只在浏览器确实发送了会话Cookie时输出，这一点与上面的SameSite情形不同 +- 如果在IdP上的登录耗时过长，断言返回时AuthnRequest ID已经不存在，登录会当场只失败一次，需要重新开始登录 - |Fess| 未在\ ``app/WEB-INF/web.xml``\ 中设置\ ``session-timeout``\ ，因此采用Servlet容器的默认值30分钟。 - 该值短于\ ``saml.request.id.ttl``\ 的3600秒，会话及其保存的AuthnRequest ID会先被丢弃， - 因此仅调大\ ``saml.request.id.ttl``\ 并不能延长用户在IdP完成登录的时间，还需要同时延长会话超时时间。 - 也正因如此，只有把TTL设置得比会话超时更短时，才会看到\ ``saml.request.id.ttl``\ 的警告 - -.. note:: - 在15.7中，同样的情况会导致\ |Fess|\ 反复重定向到IdP，使登录陷入循环。 - 15.8改为只失败一次而不再循环。配置层面的处理方法保持不变。 + 该值短于\ ``saml.request.id.ttl``\ 的3600秒，会话会先被丢弃， + 因此仅调大\ ``saml.request.id.ttl``\ 并不能延长用户在IdP完成登录的时间，还需要同时延长会话超时时间 通过反向代理时Destination验证失败 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -555,10 +529,8 @@ IdP返回的SAML响应会根据记录的ID进行校验。 当\ |Fess|\ 运行在终结TLS的反向代理或负载均衡器之后时， 即使\ ``saml.sp.base.url``\ 设置正确，断言验证也可能失败。 -原因在于SAML库将断言的\ ``Destination``\ 属性与Servlet容器重建的请求URL进行比较， -而不是与配置的ACS URL比较。当代理终结HTTPS时，\ |Fess|\ 看到的请求URL是形如\ -``http://<内部主机名>:<内部端口>/sso/``\ 的内部地址， -与IdP发送的\ ``https://fess.example.com/sso/``\ 不一致。 +断言的\ ``Destination``\ 属性会与请求到达\ |Fess|\ 时的URL进行比较。 +在终结TLS的代理之后，该URL是内部的\ ``http://``\ 地址，而不是IdP发送断言时使用的外部地址。 ``saml.sp.base.url``\ 不参与该比较，因此仅设置它无法解决问题。 设置\ ``saml.debug=true``\ 后，日志中会输出如下原因：