Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
#247 11 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
php
Bereich
api, authentication

Rechercherichtung

Beginne mit der OIDC-to-SAML-Attributzuordnungstabelle und verfolge den Authorization Code Flow, der benutzerdefinierte Claims an den userinfo endpoint oder in den id_token sendet. Definiere, wie die Zuordnung einen abwärtskompatiblen Standardwert von userinfo unterstützt, und kläre anschließend, wie ein expliziter client claims parameter mit dem konfigurierten Ziel interagieren soll. Als erledigt gilt die Aufgabe, wenn jeder konfigurierte benutzerdefinierte Claim korrekt weitergeleitet wird, ohne bestehende Standardwerte zu ändern.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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?

Vorherrschende Sprache
PHP
Sterne
50
Forks
28
Ø Merge
1 Min.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus simplesamlphp/simplesamlphp-module-oidc

Alle Issues in simplesamlphp/simplesamlphp-module-oidc

Ähnliche Issues

Weitere Issues zu PHP

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.