Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

make configurable in which part of the OIDC exchange custom claims should be sent

Đang mở
#247 11 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
php
Lĩnh vực
api, authentication

Hướng nghiên cứu

Bắt đầu với bảng ánh xạ thuộc tính OIDC-to-SAML và theo dõi authorization code flow gửi custom claims đến userinfo endpoint hoặc id_token. Xác định cách ánh xạ hỗ trợ giá trị mặc định tương thích ngược của userinfo, sau đó làm rõ cách một tham số claims tường minh của client phải tương tác với đích đã cấu hình. Hoàn tất khi mỗi custom claim đã cấu hình được định tuyến chính xác mà không thay đổi các giá trị mặc định hiện có.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement prepared

In the authorization code flow, custom claims can be sent either in the "id_token" or by querying the "userinfo".

If the client made a preference as to where the claims should be by setting the "claims parameter", the module honours this and sends accordingly.

If no preference is indicated by the client, the module currently sends custom claims always via the userinfo endpoint. As per OIDC core spec, the claims /could/ alternatively be sent directly in the id_token.

The issue at hand suggests to make configurable where a specific custom claim should be sent. The suggested place is the OIDC-to-SAML attribute mapping table, as this lists every single claim

Example, for a hypothetical custom claim "foobar":

    // The default translate table from SAML attributes to OIDC claims.
    ModuleConfig::OPTION_AUTH_SAML_TO_OIDC_TRANSLATE_TABLE => [
...
          'foobar' => [
             'attribute' => 'urn:x-randomvendor:attibute-xyz',
             'dest' => 'userinfo' # or 'id_token'
          ],

There should be a backwards-compatible default (single-string array defaults to "userinfo", to keep the current behaviour).

An open question is how to prioritise if the client did send a claim parameter, but the configured destination differs from the configured destination - which one wins?

Ngôn ngữ chính
PHP
Star
50
Fork
28
Merge trung bình
1 phút
Pull request đã merge (30 ngày)
2

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của simplesamlphp/simplesamlphp-module-oidc

Tất cả issue của simplesamlphp/simplesamlphp-module-oidc

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.