Bascule de l'ancien paramétrage OAUTH2_PROVIDER / AUTH_PROVIDERS KO

Support
1

Continuing the discussion from Personnalisation page d'authentification:

Je relance ce sujet qui nous bloque dans la mise en œuvre de nouvelles features v5 (comme la personnalisation de page d’authentification).

Pour rappel:

  • avec AUTH_PROVIDERS configuré au niveau système et sans OAUTH2_PROVIDER : ADDON sur l’écran de login OK mais API call avec token externe KO
  • avec AUTH_PROVIDERS configuré au niveau système et avec OAUTH2_PROVIDER : ADDON sur l’écran de login OK mais API call avec token externe KO
  • sans AUTH_PROVIDERS et avec OAUTH2_PROVIDER : ADDON sur l’écran de login KO mais API call avec token externe OK

Actuellement, nous conservons l’ancien mode de paramétrage (OAUTH2_PROVIDER)

2

OK, on va faire des tests dans ces différentes configurations.

[EDIT] Peux tu juste préciser de quel “addon” on parle => l’addon de la page de choix du provider (LOGON_PROVIDERS_ADDON) ? ou celui du formulaire de logon (LOGON_ADDON) interne ? Sur la copie d’écran du post d’origine c’est le premier.

4

Bonjour David,
Merci pour ton retour.
oui il s’agit bien de LOGON_PROVIDERS_ADDON.

5

OK cela signifie que la page du choix du provider doit s’afficher (avec cet addon) même s’il n’y a qu’un seul provider visible.

Combien y-a-t-il de providers déclarés dans ton OAUTH2_PROVIDERS ? et y a-t-il le provider interne ?

En relisant le code je vois effectivement une différence anormale dans la gestion du (ou des) provider(s) indiqué(s) dans OAUTH2_PROVIDER vs ceux de AUTH_PROVIDERS. De toute façon OAUTH2_PROVIDER est deprecated donc la cible c’est de faire marcher les choses via AUTH_PROVIDERS.

NB: Pour mieux gérer le cas général je pense qu’il va falloir enrichir la syntaxe de AUTH_PROVIDERS pour pouvoir indiquer explicitement si tel ou tel provider externe peut être utilisé (aussi ou exclusivement) sur le endpoint API, genre "endpoints": [ "ui", "api" ] (valeur par défaut) ou "endpoints": [ "ui" ] pour UI only ou "endpoints": [ "api" ] pour API only

6

J’en ai 2 : simplicite,renault

  • simplicite pour les accès en mode dégradé si notre IDP ne répond pas
  • renault pour les accès en mode nominal via notre IDP

L’IDP renault doit être utilisé aussi bien pour les connexions UI (fourniture du token via le flow OIDC) ou API (revalidation du token utilisateur fourni lors des appels API).

7

OK on est bien dans un cas multi IdP qui est justement le cas qui n’est actuellement pas toujours bien géré dans les fallbacks de compatibilité.

8

La correction sur le fallback (= parsing des OAUTH2_*) a été poussé en 5.1.13. Peux tu vérifier ce que ça donne dans ton cas ?

On a aussi poussé une évolution qui fait que si le addon de la page de choix du provider (LOGON_PROVIDERS_ADDON) est non vide on affiche la page, même s’il n’y a qu’un seul provider visible (avant ça faisait le redirect ad hoc dans ce cas).

PS : On doit encore creuser le cas des tokens externes sur le endpoint API

9

A priori ça ne fonctionne pas…
Voici les éléments de configuration mis en place:
OAUTH2_PROVIDER = simplicite,renault
Ressource : Disposition/default * LOGON_PROVIDERS_ADDON = (ma mention juridique en HTML)

Tant que j’utilise l’ancien système de paramétrage OAUTH2_*, ça fonctionne comme attendu. C’est a priori le dernier point qui m’empêche de migrer la configuration sur le nouveau système de paramétrage AUTH_PROVIDERS.

10

OK, si tu peux quand même essayer ce que ça donne avec UTH_PROVIDERS ça m’intéresse

PI en 5.3 on est en train de refactorer des choses à ce niveau pour pousser la logique de AUTH_PROVIDERS un peu plus loin (ex: pour pouvoir spécifier si un provider peut être utilisé sur le endpoint UI, ou API ou les deux). On a backporté quelques trucs sur le 5.1.13 mais pas tout

11

En Version=5.1.13 BuiltOn=2021-11-21 23:46

Avec le paramétrage AUTH_PROVIDERS =

[
	{ "name": "simplicite", "type": "internal" },
    { "name": "renault", "type": "oauth2", "label": "Sign in with Renault IPN", "sync": true, "client_id": "(valid id)", "client_secret": "(valid secret)" },
]

Logon / UI OK (en flow oauth2 avec un token obtenu de notre IDP) mais appel API KO (avec un token obtenu auprès de notre IDP):

HTTP/1.1 401 Unauthorized

2021-11-22 18:13:27,553|SIMPLICITE|ERROR||http://a17ad34113e5:8080||ERROR|system|com.simplicite.webapp.servlets.api.ExternalObjectServlet|service||Evénement: Authentication error: Jeton non valide

… que ce soit en paramétrant AUTH_PROVIDERS comme paramètre système ou comme paramètre de disposition.

Avec le paramétrage OAUTH2_PROVIDER = simplicite,renault et les autres paramètres OAUTH2_* le même call (token obtenu de notre IDP)

Retour 200 avec les données (le token est validé).
Sans token ou avec un token expiré: retour HTTP/1.1 401 Unauthorized

12

OK merci il y a donc toujours le pb avec AUTH_PROVIDERS, on regarde ça de plus près

13

J’ai préparé sur l’instance bcsi.renault.simplicite.io un objet de test de call API utilisant un token fourni par notre IDP : Scenarios : 000 Test basique

  • L’objet concerné récupère un token et requête une API mappée sur la même instance (auto-consommation).
  • Le user designer (mdp par défaut) est habilité.
  • Le résultat attendu est {"semanticDomains":"","semanticDomainName":"","abbreviationDefinitionEN":"test2","abbreviationName":"TEST","abbreviationDefinitionFR":"test2","rowId":"1"}

Pour basculer d’une conf à l’autre, je préfixe l’un ou l’autre des paramètres OAUTH2_PROVIDER / AUTH_PROVIDERS.

  • Actuellement, j’ai laissé la conf qui marche (OAUTH2_PROVIDER / xxxAUTH_PROVIDERS).
  • Si tu bascules dans l’autre configuration (xxxAUTH2_PROVIDER / AUTH_PROVIDERS), tu obtiens “Invalid token”…

Si tu actives des traces ou que tu redéploies une image modifiée pour l’analyse, tu pourras reproduire le scénario de test d’appel.

image
image1101×638 21.8 KB

14

Up ? (juste pour ne pas laisser le post disparaître sous la poussière)

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.