diff --git a/de/15.8/config/sso-oidc.rst b/de/15.8/config/sso-oidc.rst index ff81b62d..4a2e7f02 100644 --- a/de/15.8/config/sso-oidc.rst +++ b/de/15.8/config/sso-oidc.rst @@ -23,7 +23,7 @@ Bei der OpenID Connect Authentifizierung fungiert |Fess| als Relying Party (RP) .. note:: |Fess| verwendet den Authorization Code Flow. Das ID-Token wird nicht über den Browser, sondern direkt vom Token-Endpunkt über einen Backkanal (Server-zu-Server-Kommunikation) zwischen |Fess| und dem OP abgerufen. - |Fess| dekodiert das ID-Token und entnimmt daraus Claims (z. B. ``email`` und ``groups``), um die Benutzerinformationen zusammenzustellen, führt jedoch keine kryptografische Überprüfung der JWT-Signatur durch. + |Fess| dekodiert das ID-Token und entnimmt daraus Claims (z. B. ``email`` und ``groups``), um die Benutzerinformationen zusammenzustellen, führt jedoch keine kryptografische Überprüfung der JWT-Signatur durch. Ebenso werden die Claims ``iss`` (Aussteller), ``aud`` (Zielgruppe) und ``exp`` (Ablauf) nicht geprüft. Daher muss die Kommunikation mit dem Token-Endpunkt zwingend über HTTPS erfolgen; stellen Sie sicher, dass der Kommunikationsweg zwischen |Fess| und dem OP vertrauenswürdig ist. Für die Integration mit rollenbasierter Suche siehe :doc:`security-role`. @@ -141,7 +141,7 @@ Konfigurieren Sie die Standardgruppen und -rollen, die OIDC-authentifizierten Be Benutzer-ID, Gruppen und Rollen werden jeweils wie folgt ermittelt: - **Benutzer-ID**: Wird aus dem ``email``-Claim des ID-Tokens (JWT) bezogen. Daher muss der Scope in der Praxis ``email`` enthalten (kann der ``email``-Claim nicht abgerufen werden, ist kein ordnungsgemäßer Login möglich). -- **Gruppen**: Werden aus dem ``groups``-Claim des ID-Tokens bezogen. Ist kein ``groups``-Claim vorhanden, wird der Wert von ``oic.default.groups`` verwendet. +- **Gruppen**: Werden aus dem ``groups``-Claim des ID-Tokens bezogen. Ist kein ``groups``-Claim vorhanden, wird der Wert von ``oic.default.groups`` verwendet. Ein leeres ``groups``-Array gilt als vorhanden: ``oic.default.groups`` wird dann nicht verwendet, und der Benutzer wird als Benutzer ohne Gruppen behandelt. - **Rollen**: Es wird stets der Wert von ``oic.default.roles`` verwendet (ein Mechanismus zur Übernahme von Rollen aus ID-Token-Claims ist nicht vorhanden). .. note:: @@ -150,6 +150,9 @@ Benutzer-ID, Gruppen und Rollen werden jeweils wie folgt ermittelt: Ob übergeordnete Gruppen enthalten sind, hängt daher allein von der Claim-Konfiguration des OP ab -- anders als bei :doc:`sso-entraid`, wo |Fess| übergeordnete Gruppen über die Microsoft Graph API auflöst. + Der Claim-Wert wird unverändert zur Suchberechtigung. Ist der OP so konfiguriert, dass er + vollständige Gruppenpfade ausgibt, lauten die Werte etwa ``/uebergeordnet/untergeordnet`` und + passen damit nicht zu Dokumenten, die nur mit dem reinen Gruppennamen versehen sind. .. list-table:: :header-rows: 1 @@ -291,6 +294,11 @@ In ``app/WEB-INF/classes/log4j2.xml`` können Sie den folgenden Logger hinzufüg +.. warning:: + Steht dieser Logger auf DEBUG, werden die Claims des ID-Tokens (z. B. ``email`` und ``groups``) + in die Protokolldatei geschrieben. Setzen Sie die Protokollebene nach der Untersuchung zurück + und behandeln Sie die erzeugten Protokolle entsprechend. + Referenz ======== diff --git a/en/15.8/config/sso-oidc.rst b/en/15.8/config/sso-oidc.rst index 0c8168de..1870e7f2 100644 --- a/en/15.8/config/sso-oidc.rst +++ b/en/15.8/config/sso-oidc.rst @@ -23,7 +23,7 @@ In OpenID Connect authentication, |Fess| operates as a Relying Party (RP) and co .. note:: |Fess| uses the Authorization Code Flow. The ID Token is obtained directly from the token endpoint via a back-channel (server-to-server communication) between |Fess| and the OP, without passing through the browser. - |Fess| decodes the ID Token and extracts claims (such as ``email`` and ``groups``) to construct user information, but does NOT cryptographically verify the JWT signature. + |Fess| decodes the ID Token and extracts claims (such as ``email`` and ``groups``) to construct user information, but does NOT cryptographically verify the JWT signature. It also does not validate the ``iss`` (issuer), ``aud`` (audience) or ``exp`` (expiry) claims. For this reason, ensure that all communication with the token endpoint uses HTTPS and that the communication path between |Fess| and the OP is trusted. For integration with role-based search, see :doc:`security-role`. @@ -141,7 +141,7 @@ Configure the default groups and roles to assign to users authenticated via OIDC The user ID, groups, and roles are determined as follows: - **User ID**: Obtained from the ``email`` claim of the ID Token (JWT). For this reason, the ``email`` scope is effectively required (if the ``email`` claim cannot be obtained, login will not work correctly). -- **Groups**: Obtained from the ``groups`` claim of the ID Token. If the ``groups`` claim is not present, the value of ``oic.default.groups`` is used. +- **Groups**: Obtained from the ``groups`` claim of the ID Token. If the ``groups`` claim is not present, the value of ``oic.default.groups`` is used. An empty ``groups`` array counts as present, so ``oic.default.groups`` is not used and the user is treated as having no groups. - **Roles**: Always taken from the value of ``oic.default.roles`` (there is no mechanism to obtain roles from ID Token claims). .. note:: @@ -149,6 +149,9 @@ The user ID, groups, and roles are determined as follows: does not expand nested (transitive) groups. Whether parent groups appear is therefore decided entirely by the OP's claim configuration -- unlike :doc:`sso-entraid`, where |Fess| resolves parent groups through the Microsoft Graph API. + The claim value becomes the search permission verbatim. A provider configured to emit full group + paths therefore sends values such as ``/parent/child``, and those do not match documents tagged + with the plain group name. .. list-table:: :header-rows: 1 @@ -289,6 +292,11 @@ In ``app/WEB-INF/classes/log4j2.xml``, add the following logger to change the lo +.. warning:: + With this logger at DEBUG, the claims of the ID Token (such as ``email`` and ``groups``) are + written to the log file. Restore the log level once the investigation is over, and handle the + log output accordingly. + Reference ========= diff --git a/es/15.8/config/sso-oidc.rst b/es/15.8/config/sso-oidc.rst index 42bc075c..2115c2a2 100644 --- a/es/15.8/config/sso-oidc.rst +++ b/es/15.8/config/sso-oidc.rst @@ -23,7 +23,7 @@ En la autenticación OpenID Connect, |Fess| opera como Relying Party (RP) y cola .. note:: |Fess| utiliza el flujo de código de autorización (Authorization Code Flow). El ID Token se obtiene directamente desde el endpoint de token a través de un canal de retaguardia (comunicación servidor a servidor) entre |Fess| y el OP, sin pasar por el navegador. - |Fess| decodifica el ID Token y extrae los claims (como ``email`` y ``groups``) para construir la información del usuario, pero no realiza la verificación criptográfica de la firma JWT. + |Fess| decodifica el ID Token y extrae los claims (como ``email`` y ``groups``) para construir la información del usuario, pero no realiza la verificación criptográfica de la firma JWT. Tampoco valida los claims ``iss`` (emisor), ``aud`` (audiencia) ni ``exp`` (expiración). Por este motivo, la comunicación con el endpoint de token debe realizarse siempre mediante HTTPS, y asegúrese de que la ruta de comunicación entre |Fess| y el OP sea de confianza. Para la integración con búsqueda basada en roles, consulte :doc:`security-role`. @@ -141,7 +141,7 @@ Configure los grupos y roles por defecto que se asignarán a los usuarios autent El ID de usuario, los grupos y los roles se determinan de la siguiente manera: - **ID de usuario**: se obtiene del claim ``email`` del ID Token (JWT). Por este motivo, en la práctica es necesario incluir ``email`` en el scope (si no se puede obtener el claim ``email``, el inicio de sesión no funcionará correctamente). -- **Grupos**: se obtienen del claim ``groups`` del ID Token. Si el claim ``groups`` no existe, se utiliza el valor de ``oic.default.groups``. +- **Grupos**: se obtienen del claim ``groups`` del ID Token. Si el claim ``groups`` no existe, se utiliza el valor de ``oic.default.groups``. Un array ``groups`` vacío se considera presente, por lo que no se utiliza ``oic.default.groups`` y el usuario se trata como si no tuviera grupos. - **Roles**: siempre se utiliza el valor de ``oic.default.roles`` (no existe mecanismo para obtener roles desde los claims del ID Token). .. note:: @@ -149,6 +149,9 @@ El ID de usuario, los grupos y los roles se determinan de la siguiente manera: directorio ni expande los grupos anidados (transitivos). Por lo tanto, que aparezcan los grupos padre depende únicamente de la configuración de claims del OP, a diferencia de :doc:`sso-entraid`, donde |Fess| resuelve los grupos padre mediante la API de Microsoft Graph. + El valor del claim se convierte literalmente en el permiso de búsqueda. Si el OP está configurado + para emitir rutas de grupo completas, envía valores como ``/padre/hijo``, que no coinciden con los + documentos etiquetados solo con el nombre del grupo. .. list-table:: :header-rows: 1 @@ -290,6 +293,11 @@ En ``app/WEB-INF/classes/log4j2.xml``, puede agregar el siguiente logger para ca +.. warning:: + Con este logger en DEBUG, los claims del ID Token (como ``email`` y ``groups``) se escriben en el + archivo de log. Restaure el nivel de log cuando termine la investigación y trate la salida del log + en consecuencia. + Referencia ========== diff --git a/fr/15.8/config/sso-oidc.rst b/fr/15.8/config/sso-oidc.rst index b125265c..823bb961 100644 --- a/fr/15.8/config/sso-oidc.rst +++ b/fr/15.8/config/sso-oidc.rst @@ -23,7 +23,7 @@ Dans l'authentification OpenID Connect, |Fess| fonctionne comme une Relying Part .. note:: |Fess| utilise le flux de code d'autorisation (Authorization Code Flow). L'ID Token est obtenu directement depuis le endpoint de token via un canal arrière (communication serveur à serveur) entre |Fess| et l'OP, sans passer par le navigateur. - |Fess| décode l'ID Token pour extraire les claims (``email``, ``groups``, etc.) et constituer les informations utilisateur, mais ne procède pas à la vérification cryptographique de la signature JWT. + |Fess| décode l'ID Token pour extraire les claims (``email``, ``groups``, etc.) et constituer les informations utilisateur, mais ne procède pas à la vérification cryptographique de la signature JWT. Il ne valide pas non plus les claims ``iss`` (émetteur), ``aud`` (audience) ni ``exp`` (expiration). Pour cette raison, la communication avec le endpoint de token doit impérativement se faire en HTTPS, et veillez à ce que le chemin de communication entre |Fess| et l'OP soit de confiance. Pour l'intégration avec la recherche basée sur les rôles, voir :doc:`security-role`. @@ -141,7 +141,7 @@ Configurez les groupes et rôles par défaut à attribuer aux utilisateurs authe L'identifiant utilisateur, les groupes et les rôles sont déterminés comme suit : - **Identifiant utilisateur** : extrait du claim ``email`` de l'ID Token (JWT). Pour cette raison, le scope doit en pratique inclure ``email`` (si le claim ``email`` ne peut pas être obtenu, la connexion ne s'effectuera pas correctement). -- **Groupes** : extraits du claim ``groups`` de l'ID Token. Si le claim ``groups`` est absent, la valeur de ``oic.default.groups`` est utilisée. +- **Groupes** : extraits du claim ``groups`` de l'ID Token. Si le claim ``groups`` est absent, la valeur de ``oic.default.groups`` est utilisée. Un tableau ``groups`` vide est considéré comme présent : ``oic.default.groups`` n'est alors pas utilisé et l'utilisateur est traité comme n'ayant aucun groupe. - **Rôles** : la valeur de ``oic.default.roles`` est toujours utilisée (il n'existe pas de mécanisme permettant d'extraire les rôles depuis les claims de l'ID Token). .. note:: @@ -150,6 +150,9 @@ L'identifiant utilisateur, les groupes et les rôles sont déterminés comme sui La présence des groupes parents dépend donc uniquement de la configuration des claims de l'OP, contrairement à :doc:`sso-entraid`, où |Fess| résout les groupes parents en utilisant l'API Microsoft Graph. + La valeur du claim devient telle quelle la permission de recherche. Si l'OP est configuré pour + émettre les chemins de groupe complets, il envoie des valeurs comme ``/parent/enfant``, qui ne + correspondent pas aux documents étiquetés avec le seul nom du groupe. .. list-table:: :header-rows: 1 @@ -291,6 +294,11 @@ Dans ``app/WEB-INF/classes/log4j2.xml``, vous pouvez ajouter le logger suivant p +.. warning:: + Avec ce logger en DEBUG, les claims de l'ID Token (``email``, ``groups``, etc.) sont écrits dans + le fichier de log. Rétablissez le niveau de log une fois l'investigation terminée et traitez la + sortie de log en conséquence. + Référence ========= diff --git a/ja/15.8/config/sso-oidc.rst b/ja/15.8/config/sso-oidc.rst index 5fd88f0f..6b55bfd1 100644 --- a/ja/15.8/config/sso-oidc.rst +++ b/ja/15.8/config/sso-oidc.rst @@ -23,7 +23,7 @@ OpenID Connect認証では、|Fess| がRelying Party（RP）として動作し .. note:: |Fess| は認可コードフロー（Authorization Code Flow）を使用します。ID Tokenは、ブラウザを経由せず、|Fess| とOPの間のバックチャネル（サーバー間通信）でトークンエンドポイントから直接取得されます。 - |Fess| はID Tokenをデコードしてクレーム（``email`` や ``groups`` など）を取り出してユーザー情報を構成しますが、JWT署名の暗号的な検証は行いません。 + |Fess| はID Tokenをデコードしてクレーム（``email`` や ``groups`` など）を取り出してユーザー情報を構成しますが、JWT署名の暗号的な検証は行いません。\ ``iss``\ （発行者）、\ ``aud``\ （対象クライアント）、\ ``exp``\ （有効期限）の各クレームも検証しません。 このため、トークンエンドポイントとの通信は必ずHTTPSで行い、|Fess| とOPの間の通信経路が信頼できることを確認してください。 ロールベース検索との連携については、:doc:`security-role` を参照してください。 @@ -141,7 +141,7 @@ OIDCで認証されたユーザーに割り当てるデフォルトのグルー ユーザーID・グループ・ロールは、それぞれ以下のように決定されます。 - **ユーザーID**: ID Token（JWT）の ``email`` クレームから取得されます。このため、スコープには実質的に ``email`` を含める必要があります（``email`` クレームが取得できない場合、ログインは正しく行われません）。 -- **グループ**: ID Tokenの ``groups`` クレームから取得されます。\ ``groups`` クレームが存在しない場合は ``oic.default.groups`` の値が使用されます。 +- **グループ**: ID Tokenの ``groups`` クレームから取得されます。\ ``groups`` クレームが存在しない場合は ``oic.default.groups`` の値が使用されます。\ ``groups`` クレームが空の配列で送られてきた場合は「存在する」とみなされるため、\ ``oic.default.groups`` は使用されず、グループなしとして扱われます。 - **ロール**: 常に ``oic.default.roles`` の値が使用されます（ID Tokenのクレームからロールを取得する仕組みはありません）。 .. note:: @@ -149,6 +149,8 @@ OIDCで認証されたユーザーに割り当てるデフォルトのグルー ネストされたグループ（親グループ）の展開は行いません。 親グループが含まれるかどうかは、OP側のクレーム設定だけで決まります。 Microsoft Graph APIで親グループを解決する :doc:`sso-entraid` とは動作が異なります。 + クレームの値はそのまま検索権限になります。OP側でグループのフルパスを出力する設定にしている場合は + ``/親グループ/子グループ`` のような値がそのまま権限名になり、グループ名だけを付与した文書とは一致しません。 .. list-table:: :header-rows: 1 @@ -288,6 +290,10 @@ OPの設定画面またはDiscoveryエンドポイントから以下の情報を +.. warning:: + このロガーをDEBUGにすると、ID Tokenのクレーム（\ ``email`` や ``groups`` など）がログファイルに出力されます。 + 調査が終わったらログレベルを元に戻し、出力されたログの取り扱いに注意してください。 + 参考情報 ======== diff --git a/ko/15.8/config/sso-oidc.rst b/ko/15.8/config/sso-oidc.rst index 7bc77702..75b470d3 100644 --- a/ko/15.8/config/sso-oidc.rst +++ b/ko/15.8/config/sso-oidc.rst @@ -23,7 +23,7 @@ OpenID Connect 인증에서는 |Fess| 가 Relying Party（RP）로 동작하며, .. note:: |Fess| 는 인가 코드 플로우（Authorization Code Flow）를 사용합니다. ID Token은 브라우저를 경유하지 않고, |Fess| 와 OP 간의 백채널（서버 간 통신）을 통해 토큰 엔드포인트에서 직접 취득됩니다. - |Fess| 는 ID Token을 디코딩하여 클레임（``email`` 이나 ``groups`` 등）을 추출하고 사용자 정보를 구성하지만, JWT 서명의 암호적 검증은 수행하지 않습니다. + |Fess| 는 ID Token을 디코딩하여 클레임（``email`` 이나 ``groups`` 등）을 추출하고 사용자 정보를 구성하지만, JWT 서명의 암호적 검증은 수행하지 않습니다. ``iss``\ (발행자), ``aud``\ (대상 클라이언트), ``exp``\ (만료) 클레임도 검증하지 않습니다. 이 때문에 토큰 엔드포인트와의 통신은 반드시 HTTPS로 수행하고, |Fess| 와 OP 간의 통신 경로가 신뢰할 수 있는지 확인하십시오. 역할 기반 검색과의 연동에 대해서는 :doc:`security-role` 을 참조하십시오. @@ -141,13 +141,15 @@ OIDC로 인증된 사용자에게 할당할 기본 그룹·역할을 설정합 사용자 ID·그룹·역할은 각각 다음과 같이 결정됩니다. - **사용자 ID**: ID Token（JWT）의 ``email`` 클레임에서 취득됩니다. 이 때문에 스코프에는 실질적으로 ``email`` 을 포함해야 합니다（``email`` 클레임을 취득할 수 없는 경우 로그인이 올바르게 이루어지지 않습니다）. -- **그룹**: ID Token의 ``groups`` 클레임에서 취득됩니다. ``groups`` 클레임이 존재하지 않는 경우 ``oic.default.groups`` 의 값이 사용됩니다. +- **그룹**: ID Token의 ``groups`` 클레임에서 취득됩니다. ``groups`` 클레임이 존재하지 않는 경우 ``oic.default.groups`` 의 값이 사용됩니다. ``groups`` 클레임이 빈 배열로 전달된 경우에는 존재하는 것으로 간주되므로 ``oic.default.groups`` 가 사용되지 않으며, 그룹이 없는 것으로 처리됩니다. - **역할**: 항상 ``oic.default.roles`` 의 값이 사용됩니다（ID Token의 클레임에서 역할을 취득하는 구조는 없습니다）. .. note:: |Fess| 는 ``groups`` 클레임의 값을 그대로 사용하며, 디렉토리 조회나 중첩 그룹(상위 그룹)의 확장은 수행하지 않습니다. 상위 그룹이 포함되는지 여부는 OP 측의 클레임 설정에 따라서만 결정됩니다. Microsoft Graph API로 상위 그룹을 해결하는 :doc:`sso-entraid` 의 동작과는 다릅니다. + 클레임의 값은 그대로 검색 권한이 됩니다. OP 측에서 그룹의 전체 경로를 출력하도록 설정한 경우 + ``/상위그룹/하위그룹`` 과 같은 값이 그대로 권한 이름이 되며, 그룹 이름만 부여한 문서와는 일치하지 않습니다. .. list-table:: :header-rows: 1 @@ -287,6 +289,10 @@ OP의 설정 화면 또는 Discovery 엔드포인트에서 다음 정보를 취 +.. warning:: + 이 로거를 DEBUG로 설정하면 ID Token의 클레임(``email`` 이나 ``groups`` 등)이 로그 파일에 출력됩니다. + 조사가 끝나면 로그 레벨을 원래대로 되돌리고, 출력된 로그의 취급에 주의하십시오. + 참고 정보 ========= diff --git a/zh-cn/15.8/config/sso-oidc.rst b/zh-cn/15.8/config/sso-oidc.rst index e20fb697..6c129d04 100644 --- a/zh-cn/15.8/config/sso-oidc.rst +++ b/zh-cn/15.8/config/sso-oidc.rst @@ -23,7 +23,7 @@ OpenID Connect认证的工作原理 .. note:: |Fess| 使用授权码流程（Authorization Code Flow）。ID Token不经过浏览器，而是通过 |Fess| 与OP之间的后端通道（服务器间通信）直接从令牌端点获取。 - |Fess| 通过解码ID Token来提取声明（如 ``email`` 和 ``groups``）以构建用户信息，但不对JWT签名进行密码学验证。 + |Fess| 通过解码ID Token来提取声明（如 ``email`` 和 ``groups``）以构建用户信息，但不对JWT签名进行密码学验证。也不会校验 ``iss``\ （颁发者）、\ ``aud``\ （受众）和 ``exp``\ （过期时间）声明。 因此，与令牌端点的通信必须使用HTTPS，并请确认 |Fess| 与OP之间的通信路径是可信的。 有关基于角色的搜索集成，请参阅 :doc:`security-role`。 @@ -141,13 +141,15 @@ OpenID Connect认证的工作原理 用户ID、组和角色分别按如下方式确定： - **用户ID**：从ID Token（JWT）的 ``email`` 声明中获取。因此，范围中实际上必须包含 ``email``\ （如果无法获取 ``email`` 声明，登录将无法正常完成）。 -- **组**：从ID Token的 ``groups`` 声明中获取。如果 ``groups`` 声明不存在，则使用 ``oic.default.groups`` 的值。 +- **组**：从ID Token的 ``groups`` 声明中获取。如果 ``groups`` 声明不存在，则使用 ``oic.default.groups`` 的值。如果 ``groups`` 声明是空数组，则视为存在，因此不会使用 ``oic.default.groups``，该用户将被视为没有任何组。 - **角色**：始终使用 ``oic.default.roles`` 的值（不存在从ID Token声明中获取角色的机制）。 .. note:: |Fess| 直接使用 ``groups`` 声明中的值，不会查询目录，也不会展开嵌套组（父组）。 因此，是否包含父组完全取决于OP侧的声明配置。 这与通过Microsoft Graph API解析父组的 :doc:`sso-entraid` 不同。 + 声明的值会原样成为检索权限。如果OP侧配置为输出组的完整路径， + 则会发送 ``/父组/子组`` 这样的值并原样成为权限名称，与仅标记了组名的文档不匹配。 .. list-table:: :header-rows: 1 @@ -286,6 +288,10 @@ OP侧配置 +.. warning:: + 将该日志记录器设置为DEBUG后，ID Token的声明（如 ``email`` 和 ``groups``）会被写入日志文件。 + 调查结束后请将日志级别恢复原状，并谨慎处理输出的日志。 + 参考信息 ========