From b508249ff59b6ca47560c1b37ea33334319916c3 Mon Sep 17 00:00:00 2001 From: Shinsuke Sugaya Date: Sun, 16 Aug 2026 09:03:07 +0900 Subject: [PATCH] docs(sso): state what the OpenID Connect ID token check does and does not cover Four points where sso-oidc.rst left a reader with the wrong expectation, in all seven languages. - The note that the JWT signature is not verified stops there, which reads as if the rest of the token were checked. The `iss`, `aud` and `exp` claims are not validated either: an expired token, one issued for a different client, and one from a different issuer are all accepted. That is the same trust argument the existing note makes about the transport, so it belongs in the same place. - "If the groups claim is not present, oic.default.groups is used" does not say which side of the line an empty array falls on. It counts as present: the default is not applied and the user ends up with no groups. Providers differ on whether a user in no group gets an empty array or no claim at all, so the two configurations behave differently. - The note that group values are used as they are explains that parent groups are not expanded, but not that the value becomes the search permission verbatim. A provider set to emit full group paths sends `/parent/child`, and documents tagged with the plain group name then match nothing. - The debug logger the troubleshooting section recommends writes the ID token claims, including the user's email address and group membership, to the log file. Say so, and say to put the level back afterwards. --- de/15.8/config/sso-oidc.rst | 12 ++++++++++-- en/15.8/config/sso-oidc.rst | 12 ++++++++++-- es/15.8/config/sso-oidc.rst | 12 ++++++++++-- fr/15.8/config/sso-oidc.rst | 12 ++++++++++-- ja/15.8/config/sso-oidc.rst | 10 ++++++++-- ko/15.8/config/sso-oidc.rst | 10 ++++++++-- zh-cn/15.8/config/sso-oidc.rst | 10 ++++++++-- 7 files changed, 64 insertions(+), 14 deletions(-) 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``）会被写入日志文件。 + 调查结束后请将日志级别恢复原状，并谨慎处理输出的日志。 + 参考信息 ========