Paramètres de requête des applications

Une application peut fournir des valeurs aux transformations de claims, telles qu’un identifiant de profil ou une liste de services. Configurez Allowed request parameters dans son inscription d’application pour rendre les valeurs sélectionnées disponibles sous forme de claims _local:params:{name}.

Configurer les paramètres

Activez Show advanced et configurez Allowed request parameters dans l’inscription de l’application.

Ajoutez chaque nom de paramètre autorisé. La liste est vide par défaut. Les noms sont enregistrés en minuscules ; séparez les mots par des traits de soulignement, par exemple profile_id.

FoxIDs sépare automatiquement les valeurs des paramètres au niveau des espaces. Une valeur sans espace produit un claim ; une liste séparée par des espaces produit un claim par élément. Les valeurs conservent leur casse. Par exemple :

profile_id=16b66fb6-9f88-4a10-b489-8e54f48f76a4&departments=Sales%20Support

Lorsque profile_id et departments sont configurés comme noms de paramètres autorisés, les transformations reçoivent :

_local:params:profile_id = 16b66fb6-9f88-4a10-b489-8e54f48f76a4
_local:params:departments = Sales
_local:params:departments = Support

Les espaces en début et en fin de valeur ainsi que les espaces répétés sont ignorés. Les guillemets n’ont pas de signification particulière. Envoyez la liste dans une seule occurrence du paramètre.

Requêtes prises en charge

L’échange d’un code d’autorisation et les requêtes avec jeton d’actualisation utilisent les claims du grant existant ; les paramètres de requête supplémentaires ne sont pas mis à la disposition des transformations.

Pour SAML, envoyez les paramètres avec le message du protocole. Avec HTTP-Redirect, ajoutez-les après la création de l’URL de redirection signée afin que le message SAML et la signature restent intacts. Ces paramètres supplémentaires se trouvent en dehors du message SAML signé.

Limites

Les noms de paramètres sont comparés sans tenir compte de la casse. Les noms non configurés sont ignorés. Les paramètres configurés doivent apparaître une seule fois et contenir des valeurs non vides qui ne se composent pas uniquement de caractères d’espacement. Un paramètre répété, y compris le même nom dans la chaîne de requête et le formulaire, ou une valeur dépassant les limites entraîne le rejet de la requête avec une erreur de protocole. Les séparateurs de liste ne comptent pas dans la longueur totale des valeurs.

Utiliser les paramètres dans les transformations

Lors d’une connexion dans le navigateur, les paramètres sont disponibles dès les transformations de claims de premier niveau de la méthode d’authentification. Ils restent disponibles dans les ensembles de transformations suivants, y compris Extended UI et les transformations de l’application, pendant tout le flux de connexion. Chaque ensemble reçoit les valeurs initialement acceptées sous forme de claims locaux.

Utilisez une transformation Map pour copier une valeur dans un claim ordinaire à émettre ou dans un claim _internal: pour un traitement ultérieur. Pour conserver une sélection autorisée lors de connexions ultérieures à des applications, mappez-la à un claim _session: dans la méthode d’authentification. Une connexion ultérieure peut utiliser le paramètre fourni ou, en son absence, le claim de session enregistré. Voir claims locaux, internes et de session.

Les paramètres sont des données fournies par l’appelant. Avant d’utiliser un identifiant de profil pour une impersonation ou une autre opération privilégiée, vérifiez les autorisations de l’utilisateur authentifié et l’éligibilité de l’utilisateur cible. Un identifiant fourni désigne la cible demandée ; il n’autorise pas l’accès. Évitez d’envoyer des secrets dans les paramètres de la chaîne de requête.

Documentation associée

• Tâches de transformation de claims
• Applications OpenID Connect
• Applications SAML 2.0
• Applications OAuth 2.0
• Configuration des applications via la Control API