Bonjour,
j’initie ce fil pour lister les bugs (ou problèmes rencontrés)…
Dans la console des logs système, lorsque je clique sur le cadenas, l’image disparaît.
Ok ce composant n’est plus très entretenu, on a pas dû le retester en 5.2. On regarde.
Pour rappel les logs sont remontées dans la console du navigateur via websockets. Sur les réseaux où les websockets fonctionnent c’est la meilleure solution pour consulter les logs
Bravo, tu as trouvé la dernière URI d’icone en dur dans le code Java de la plateforme (on a corrigé jusqu’en 4.0 maintenance) !
Le pb ne se manifestait pas en 5.1 car les anciennes icônes PNG étaient encore présentes, elles ont été définitivement supprimées en 5.2.
Cool 
J’ai gagné quoi ? (en dehors du droit d’enfiler mes websockets)
L’appel à une API mappée (RESTMappedObject /api/ext/xxx → sans passer par le URI_MAPPINGS) est en erreur :
curl -X GET -H 'Content-Type:application/json' -H 'Accept:application/json' -d '' -H 'Authorization:Bearer ...valid token...' -H 'apikey:...' -H 'Cache-Control:no-cache' 'https://bcsi.renault.simplicite.io/api/ext/BCSIAPILegalServicesV1/openapi.yml'
Extrait de la log système :
2022-02-04 10:34:12,878|SIMPLICITE|ERROR||http://renault.simplicite.io:10028||ERROR|system|com.simplicite.webapp.servlets.api.ExternalObjectServlet|service||Event: Authentication error: Cannot invoke "org.json.JSONObject.getString(String)" because "prv" is null
AUTH_PROVIDERS =
[
{ "name": "simplicite", "type": "internal", "visible": true },
{
"name": "renault",
"type": "oauth2",
"label": "Sign in with renault",
"sync": true,
"client_id": "...",
"client_secret": "...",
"scopes": "openid arca role-bca-irn68521",
"authorize_url": "https://idp2.renault.com/nidp/oauth/nam/authz",
"token_url": "https://idp2.renault.com/nidp/oauth/nam/token",
"tokeninfo_url": "https://idp2.renault.com/nidp/oauth/nam/tokeninfo",
"tokeninfo_mappings": {
"login": "user_id"
},
"userinfo_url": "https://idp2.renault.com/nidp/oauth/nam/userinfo",
"userinfo_mappings": {
"login": "uid",
"firstname": "firstname",
"latstname": "lastname",
"email": "mail",
"phone": "phone"
}
}
]
USERTOKENS_MODE = jwt
USE_USERTOKENS = yes
Y-a-t-il un stacktrace plus détaillé dans les logs ?
A priori je vois un seul endroit dans le code qui pourrait correspondre à ce message d’erreur et c’est au niveau de la validation d’un token JWT externe. Si c’est là, tu dois donc avoir ce pb aussi sur des APIs non mappées.
On va rendre le code un peu plus robuste à cet endroit pour remonter un message plus explicite (en l’occurrence le fait qu’aucun provider paramétré ne matche l’issuer trouvé dans le token JWT)
Quelle est la ton paramétrage d’authent ? En 5.2 il faut utiliser AUTH_PROVIDERS en priorité.
Il n’y a que ce message intercalé dans d’autres message d’INFO et aucune stacktrace.
Je suis bien par défaut configuré avec AUTH_PROVIDERS et sans OAUTH_* xxx.
J’ai mis à jour ma réponse précédente avec les paramètres pendant que tu répondais.
Quand tu decode ton token JWT externe quel est la valeur pour l’attribut issuer ?
Si ce n’est pas renault = le nom du provider tu peux ajouter ce nom d’issuer JWT en tant que jwt_issuer dans le AUTH_PROVIDERS
Dans le même ordre d’idée il faut configurer le secret de signature JWT en tant que jwt_secret dans le AUTH_PROVIDER (à ce stade il n’est pas possible d’inhiber le check de secret mais on pourrait l’envisager si besoin)
Je peux mettre à jour ton instance 5.2 bcsi avec la version buildée à l’instance (correction du bouton des logs + robustesse sur la recherche d’issuer JWT) => tu veux que je le fasse ?
Ah, ok…
Voici ce que j’ai: "iss": "https://idp2.renault.com/nidp/oauth/nam"
OK il faut donc ajouter "jwt_issuer": "https://idp2.renault.com/nidp/oauth/nam" au provider renault dans le AUTH_PROVIDERS.
Quid du secret de signature du token, l’as tu ? Peut être est-ce la même valeur que le client secret ?
Sinon comme répondu précédemment, je peux voir pour ne pas vérifier la signature, en l’état ce n’est pas inhibable.
C’est fait.
J’ai désormais le retour “No JWT token secret for JWT token issuer”;
Oui c’est ce que je dis plus haut => il faut le secret (dans jwt_secret) pour pouvoir vérifier la signature du token JWT
Si tu ne peux pas l’obtenir alors on fera évoluer les choses pour que cette vérification puisse être facultative.
En l’état avec les tokens JWT c’est ceinture + bretelles = vérification de la signature du token et appel du token info de l’IdP, il va peut être falloir être plus souple à ce niveau.
A priori, je n’aurais jamais le secret du token car il est gardé (secret) par l’émetteur de l’appel.
OK je fais l’évolution.
C’est tout de même bizarre de ne pas le donner car c’est justement un des intérêts des tokens JWT de pouvoir valider qu’ils ont bien été fournis par celui qui prétend les avoir fournis via ce check de signature via un secret partagé…
C’est pertinent, je remonte le point à nos API référents 
Mais s’ils préfèrent que cette vérification se fasse par un appel au token info c’est bon aussi mais ça coute un appel HTTP en plus.
De toute façon dans Simplicité on ne fait la vérification que lorsqu’on voit le token pour la première fois donc c’est pas beacoup plus “couteux”.
J’ai poussé la MAJ de la 5.2 sur le SIM renault.simplicite.io => je te laisse faire l’upgrade de ton instance
C’est fait.
à présent, j’ai ceci : (avec un token fraichement créé)
2022-02-04 12:46:43,277|SIMPLICITE|ERROR||http://renault.simplicite.io:10028||ERROR|system|com.simplicite.webapp.servlets.api.ExternalObjectServlet|service||Event: Authentication error: Invalid token
Payload:
{
"iss": "https://idp2.renault.com/nidp/oauth/nam",
"jti": "c324dffd-52d5-4887-954e-77f5e40c7314",
"aud": "539f6e6b-30a0-453a-8757-73453007516a",
"exp": 1643976979,
"iat": 1643975179,
"nbf": 1643975149,
"sub": "39613763383938322d66646366313165372d38353032396439342d6233373737633866",
"_pvt": "MDLtyaB/uAZVt1ZBZMUpYqEwfe5y2Y8speEFDOh/RWTZiMimLiy/R6Z/0cgLOKGGB/w5oWPKSB5C2IfwTfVl1c5NmqQrftWuQv4EPx8CiYAOiRZCwuLU9Q7Mr3a0rYNUqXdt/PoazQKVkbduhWBj/EpQMVuwbdTVOpgik5RcJly5W6feEIqJSk7G/n+t+oJWOfMrd2Il61hVzMQmCWmNzAArGtVLBL368J5XFYgeZciJ+xMTzf8+6HxhVtlZsspFLN9c2yi8XQhE+YTPh3qNUtvWWOQgQ3CpHPc+DIzmDQ4/Rn8FuOOPnHpPRH6CkGRrjkk5nZ6/WIBRdrnP/svzeHK1huDN5jTY8S6IIKPL1aHhGZM5SBERW9+z/IdEq/yoXUdEV9OBkf4PwZj3CN4e/jaZGiklV/uXGu6eGwSavZDP1G4GGTs2hK5bwy0EzWuiNnO6gOlD7yeyQt9vDygYqrcg2QCYtUl4bZstw/KJRzeevG5gpX7gp/ZMvkhmMAX9a1U5CU34np3H4yhxc2tChYnVBBZ/z9OnLuuKCbaEhLM=.7",
"scope": [
"arca",
"role-bca-irn68521"
],
"uid": "awbca02",
"firstname": "Irn-68521",
"userDirectory": "arca",
"postOfficeBox": "FREQVNOV389",
"preferredLanguage": "EN",
"costCenter": "AA50471",
"personType": "catAPPI",
"lastname": "Bca",
"_target": "IdentityProvider"
}
Header:
{
"kid": "1767",
"typ": "JWT",
"alg": "RS256"
}
Ok vu.
J’avais zappé une 2ème vérification du flag issu de la validation un peu plus loin… on va y arriver mais on est pas l’abri d’un pb un peu plus loin (la partie appel du token info n’a pas pu être testée jusqu’ici)
En tout cas la MAJ est poussée sur le SIM => je te laisse mettre à jour l’instance
Alors, j’ai un retour de notre expert IDP.
Voici ce qu’il dit : “Un jwt est autoporteur d’information permettant à tout récepteur de le valider en allant recueillir des informations supplémentaire publié par celui (l’idp) qui a signé le jeton. Il est inutile de faire un appel HTTP à tokeninfo. La bonne manière consiste à vérifier le jeton en toute autonomie sans appel externe en vérifiant : la validité de la signature, l’expiration, que l’issuer du jeton est considéré comme de confiance (ca c’est hardcodé).”
Donc il n’est pas demandé de renforcer le contrôle en vérifiant que le token a bien été fourni par celui qui prétend l’avoir fourni. Mais c’est un plus que nous pouvons conserver dès lors que c’est déjà implémenté et que le check n’est fait qu’une fois lors de l’initialisation de la session.