C’est passé 
.
ça semble également OK via le mapping d’URI.
Je continue mes tests.
OK super.
Sur le token JWT j’ai peut être mal compris mais pour contrôler la validité de la signature j’ai besoin de connaitre le secret avec lequel il a été signé. Sinon ça ne garantit pas l’authenticité du dit token, juste qu’il est bien formaté et qu’il n’est pas expiré (ça on le fait dans tous les cas).
En tout cas ce mécanisme à base de secret est utilisé dans le cadre des tokens issus de Simplicité avec en plus une vérification locale (= l’équivalent conceptuel de l’appel du token info pour un token externe)
Ce que me dit l’expert c’est que le JWT contient tout ce qu’il faut pour pouvoir être validé.
C’est ce que fait https://jwt.io qui indique
Ok même si je comprends pas trop comment on peut valider une authenticité sans un élément externe connu uniquement de ceux qui s’échangent l’info… On ne doit pas parler de la même “validation” je pense.
En tout cas ce qu’on fait c’est :
- on decode le token JWT notamment pour vérifier sa non expiration
- si un secret est renseigné, on vérifie la signature avec ce secret
- si une URL token info est renseignée, on l’appelle pour vérifier que le token est bien connu de l’IdP
Bref, à vous de voir si vous voulez faire 2 et/ou 3
1 Like
Merci. Une dernière question sur ce sujet : ce fameux secret est censé être dans le token, fourni par l’appelant dans un HEADER additionnel ou fourni en amont du call par l’appelant et enregistré de notre côté pour l’uid indiqué dans le token ?
J’ai l’impression que ce que tu décris correspond au mode d’appel de nos API sécurisées (TLS + certificat P12) → dans ce cas, c’est notre Apigee qui valide le tout et apporte la garantie que notre backend est bien appelé via ce canal TLS qui ne laissera passer que les appelant fournissant un certificat valide).
Bonjour David,
les modifications apportées sur la 5.2 concernant la validation tu token sont-elles “backportables” en 5.1 ou bien est-ce trop dépendant du nouveau code refondu en 5.2 ?
Je voudrais en effet pouvoir déployer la nouvelle configuration AUTH_PROVIDERS en amont de la release 5.2 pour pouvoir tester en conditions réelles. Nous avons en effet de nombreux cas de figures avec nos consommateurs d’API que je ne peux pas tester sur simplicite.io. Si c’est trop impactant, je vais avancer le deploy de la 5.2 de notre côté mais ça risque de perturber le delivery de mes PL (avec des DEV réalisés en 5.2 et des recettes métier et la production en 5.1).
La 5.1 vit ses dernières semaines, on n’y backporte plus rien à part du strict correctif. Et de toute façon on parle ici d’un refactoring beaucoup trop important pour être backporté.
Pour rappel, une fois releasée la 5.2 remplacera la 5.1 (comme la 5.1 a remplacé la 5.0), il n’y aura pas de branche de maintenance 5.1 (comme il n’y a pas eu de branche de maintenance 5.0). Nous ne gérons de branche de maintenance que pour les versions majeures (ex: la 5.x finale restera maintenue 3 ans à date de la release de la 6.0).
Si tu veux tester des cas particuliers avant la release officielle de la 5.2, il faudrait te déployer une instance 5.2 beta et y faire ces tests en // de la poursuite de tes processus de dev/test/prod en 5.1. Il faut clairement éviter de faire du dev en 5.2 et de déployer ces devs en prod en 5.1.
OK merci je comprends.
On va voir comment gérer ça au mieux.
En attendant tu peux aussi me décrire les cas particuliers en question pour que je regarde comment ils peuvent être traités dans le contexte de la 5.2.
Ex: si on parle de tokens API JWT issus d’autres IdP ça devrait ne pas poser de pb.
Ce qui change en 5.2+ c’est qu’un appel API sans token est désormais considéré comme un appel fait par le user public, la conséquence c’est que désormais seul le /api/login traite le username+password (pour délivrer un token), les autres /api/* ne gèrent plus que le token comme élément d’ident/authent.
Corrolaire: en 5.2+ il n’est plus nécessaire d’ajouter un user “technique” avec des droits “publics” pour exposer des APIs “publiques”
Surtout c’est l’occasion de refactorer les éventuels appels au endpoint “UI public” (/) qui n’a jamais été un endpoint de service mais un endpoint UI => donc avec une session Tomcat à maintenir via un cookie et strictement aucun mécanismes de scalabilité tel que ce qui existe sur le endpoint API (/api) => utiliser ce endpoint UI public pour exposer des APIs “publiques” a donc toujours été un anti-pattern qu’il faut désormais proscrire totalement car plus rien ne le justifie.
Oui, il s’agit essentiellement de pouvoir tester dans notre environnement (apigee, idp) avec les clients ayant souscrit à nos API → je ne pourrai pas y ajouter l’environnement bcsi.renault.simplicité.io.
J’ai demandé un contrat spécifique à notre IDP sur cette instance pour pouvoir tester l’intégration OIDC et les appels API (auto consommation) mais ça reste assez limité.
Je vais faire le tour de tous les appels API pour vérifier que tout passe bien par /api/ext/xxx (pas de /ext/xxx qui traînent par exemple). En l’occurrence, si tous les appel utilisent l’URI_MAPPING, c’est déjà le cas. Je check néanmoins.
Je vais aussi vérifier les habilitations octroyées à PUBLIC.
à ce sujet: quel est la langue par défaut appliquée dans le cadre des appels API sans token ? celle du user public ?
Oui c’est le user public qui est utilisé pour instancier le grant, donc ça utilise la langue configurée sur ce user.
OK donc on va conserver nos users public_en et public_fr pour pouvoir servir plus simplement nos sites en anglais et en français.
Je ne pense pas qu’il soit possible de spécifier la langue préférée lors de chaque appel (cf. valeurs de listes traduites dans les méta-données servies par les services Simplicité).
Non effectivement, en l’état, changer de langue niveau grant API n’est pas possible.
Poursuite des tests : test plan conso API / jMeter:
Le plan de tests consiste à dérouler des séquences d’appels de 2 minutes avec un nouveau token par séquence. Chaque séquence initialise son propre token puis 1, 3, 5 puis 8 threads consommateurs qui appellent l’API en parallèle (avec le token fourni pour la séquence).
Je constate que le nombre de sessions privées augmente de 2 à chaque fois que jMeter lance une nouvelle séquence d’appels (4 séquences → 4 tokens). Ce nombre ne redescend jamais (restitué dans l’onglet “Monitoring / Historique” ou dans l’écran “Vider le cache” :
-
Début du test plan jMeter :
-
Nombre de sessions pendant la séquence “5 simultaneous…” :
-
Logs système à ce moment là :
-
Monitoring / Historique + Data + Threads :
De ce que je comprend de ton test c’est normal => le cache des grants API est basé sur les token => à chaque token correspond un grant (et donc un pool d’objets) i.e. une “session” API (même si le terme n’est plus adapté)
Le “ménage” des grants API se fait sur la base de l’expiration des tokens, il y a une tâche planifiée qui lance ce ménage toutes les heures, en fonction de la durée de validité des tokens et du volume de token utilisé il peut être pertinent d’augmenter la fréquence d’exécution de cette tâche.
PS: Le fait que le compteur s’incrément de 2 est sans doute un bug de comptage, on va regarder ce point
Réponse rapide, merci 
…
Ok donc le nombre de session doit redescendre automatiquement après le ménage / expiration des tokens.
Je viens d’exécuter la tâche cron et ça m’a affiché “No expired tokens to delete”…
2022-02-08 20:05:12,356|SIMPLICITE|INFO||http://renault.simplicite.io:10028||INFO|a068181|com.simplicite.objects.System.CronTable|forceExecute||Evénement: Force action ClearUserTokens of object UserToken
Les tokens ont une durée de vie de 30 minutes donc les premiers auraient déjà dû expirer… Je vais dîner et je re-check ça 
Exemple de token :
{
"access_token":"eyJraWQiOiIxNzY3IiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL2lkcDIucmVuYXVsdC5jb20vbmlkcC9vYXV0aC9uYW0iLCJqdGkiOiJhM2YyOTMzNC00NmVlLTQyZDUtODU5OC05ZjQ4NjE4Mzg0OWEiLCJhdWQiOiI1MzlmNmU2Yi0zMGEwLTQ1M2EtODc1Ny03MzQ1MzAwNzUxNmEiLCJleHAiOjE2NDQzNDkxMTYsImlhdCI6MTY0NDM0NzMxNiwibmJmIjoxNjQ0MzQ3Mjg2LCJzdWIiOiIzOTYxMzc2MzM4MzkzODMyMmQ2NjY0NjM2NjMxMzE2NTM3MmQzODM1MzAzMjM5NjQzOTM0MmQ2MjMzMzczNzM3NjMzODY2IiwiX3B2dCI6ImxLcFM3bTY4VVA2OWNhbGx5bWtiTXU2SS9ONEs4bGdsRHVlUkczdDU2SVFQcmFjT2JvOVkzdlRTdVhJTGNOS1A2bS9UMnZBTzJBTzBoU0lKaFZqUzhua2VITTBoazA0RHFzbkoxN2pvNnJ2ZUQ0bGRKb1o0Q3IyQ0h1cDRSNm01QS83Uzlwb0dWbkhtOVJMeEpHVGJLUmxkTHQvOXh6eEViVWhyYW5nZkJPRWoxWmpJTCs2ZWhHVUhOMXlTcnpSWVJLNmhUVWJwRmlBZEplTzVHMVZsSGlyOTl3MGZmbGtMbE5BKzRTZ1krTHhjVDBYRlRqMVMzQjlNNGtlbXNvRHpBanQySkIvT1BJRWNrdEJCU2paSDB6OGVvZzFjM0xRY0tRRnRWYktad2ptMlh1VGR5aDdsMkhzeVlEbkk0M0Vzc0d6cWVQY0JCZ2IyZEIyQkEvQ0hQc3lmaDFCZ05FejZJbEpWK1A0UmorVW1LSFAyNnJHKzNTYkNMSUo1RnZ0OGlzRHBLNE9LVVdPL1ZiV0Y2Ujh6ZnZ6RFpGamxZYWE5M0FwVmc2d2Vha05SWkNabFRwdEp4Q1BMYXdWZ1NtSkc3OHJHV1lzUDhtT2JrOEMrMVhqakhabU03SzV2L0Q1S1MxSFJuQUNSUGYwQUUyRm9CNldBRE4rbzhvS3E3SklLcTJUdVZiTWZMMk4zQnFuaHFmM1RNNWpaRVNyQXdhWVpZT3FqVlUzU29QND0uNCIsInNjb3BlIjpbXSwiX3RhcmdldCI6IklkZW50aXR5UHJvdmlkZXIifQ.ms6u87cosKymoQ3OZRwg3aVLPmXYiekroijnIZcvqjVfxc5b0IKVTRTKG1f4ZYacXa2EzhGJJGrZ1hV9JvZR5PLCORw2BMMSpWFXxx6S5d6uru_0cRQdVbht9ZIT2itKTsyBo-4VX1pOAiwXby1CKbl6RhYkiP6LWZoto8kG_oKOoJOt-zaUYRVcGR1puVsDu8_LLjuvGrojKTYp_ZSdLzD0Y3U-xR2S03SK1TkkWMciNuHq46z07yPwNxEjAc6JaggyfS6WT5nfbzD0xYhjm90VeJHt0LVQBYcH5CQ2Hyjc9Y_dEbClX4R82Qtl0-Ko3BXE7Qyey2zXklMfIg5yPg",
"token_type":"bearer",
"expires_in":1799
}
J’ai relancé le même test plan et je confirme qu’aucun userToken n’est ajouté dans cette table…
du coup ça pourrait expliquer pourquoi aucun de ces tokens (et donc des grants associés?) n’est nettoyé ?
Je précise qu’il s’agit du comportement observé sur les derniers builds 5.1 depuis la 5.1.25.
Nouveaux screenshots du monitoring après dîner :
Exécution de la tâche cron sans effet :
Tentative de clean des tokens manuelle :
Les tokens externes ne sont pas (plus) mis dans la table des tokens. Du coup ce que j’ai raconte sur la tâche cron (qui purge cette table) est donc sans objet ici, car ça ne concerne que les tokens internes.
Par contre, la mécanique du cache de grants APIs est sensée évincer de la mémoire les grants associes à des tokens expirés (indifféremment les internes et externes) ainsi que les plus anciens lorsqu’on atteint les limites de taille de cache. Il y a peut être un pb au niveau de ces stratégies d’éviction, je vais creuser.
NB: Dans le cas des tokens internes, la tâche de purge de la table en profite aussi pour forcer l’éviction du grant correspondant du cache. Le stockage en table des tokens interne ne sert finalement qu’à les conserver au delà d’un arret-relance.