Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#247 11 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
php
Domaine
api, authentication

Piste de recherche

Commencez par la table de mappage des attributs OIDC-to-SAML et suivez le authorization code flow qui envoie les custom claims au userinfo endpoint ou dans le id_token. Définissez comment le mappage prend en charge une valeur par défaut rétrocompatible de userinfo, puis déterminez comment un paramètre de claims explicite du client doit interagir avec la destination configurée. Le travail est terminé lorsque chaque custom claim configuré est correctement acheminé sans modifier les valeurs par défaut existantes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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?

Langage dominant
PHP
Étoiles
50
Forks
28
Merge moyen
1 min
PR mergées (30 j)
2

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de simplesamlphp/simplesamlphp-module-oidc

Toutes les issues de simplesamlphp/simplesamlphp-module-oidc

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.