Bonjour,
Dans le cadre de la mise œuvre d’un webservice “habilitation public” permettant la création d’un user, nous avons dans l’entête une entrée Authorization avec un contenu Bearer +token (le token est non Simplicité). Nativement, le socle essaie de valider le token via JWT. Comment peut-on bypasser cette vérification ? la validation du token se faisant par un système spécifique au client.
Utilisation de la class : RESTServiceExternalObject
2024-03-29 09:54:24,556|SIMPLICITE|ERROR||http://alpha:8080/simplicite|/simplicite|ERROR|system|com.simplicite.webapp.servlets.api.ExternalObjectServlet|service||Event: Authentication error: Invalid token
2024-03-29 09:54:24,555|SIMPLICITE|ERROR||http://alpha:8080/simplicite|/simplicite|ECORED0001|system|com.simplicite.webapp.tools.ServletTool|validateJWTToken||Error Unable to process JWT token: The token was expected to have 3 parts, but got 0.
Il faut exposer cette API en public et traiter son authent custom manuellement.
En tapant sur /api ça passe nécessairement par une ident/authent Simplicité, i.e. essayer de retrouver un user déclaré dans Simplicité via un provider dûment déclaré.
Bref pour moi c’est un pb de conception, pas d’ident/authent
Merci, Cela nous a permis d’avancer sur le sujet.
Néanmoins, il nous reste un point qui nous pose problème, en faisant N appels Postman
Le 1er appel est bien géré par la méthode getAuthTokenInfo ce qui semble indiquer que le paramétrage est fonctionnel,
Un 2eme appel, on reçoit un message d’erreur de jeton :
ExternalObjectServlet|service||Evénement: Authentication error: Jeton expiré
ServletTool|getAPIGrant||Erreur The cached token is expired since 1970-01-01 01:00:10
Un 3eme appel est bien géré par la méthode getAuthTokenInfo
Un 4eme, on reçoit un message d’erreur de jeton
et ainsi de suite
Je ne comprends pas la logique de cette ident/authent…
Sur /api il y a 2 cas d’usage:
si aucun token n’est passé, ni via le header Authorization ni via le header X-Simplicite-Authorization, c’est alors le user public qui est implicitement utilisé (et il est toujours possible d’implémenter une pseudo-logique d’authentification de l’appel via une info authentifiante passée d’une autre manière)
si un token est passé via un des headers ci-dessus, il doit obligatoirement servir à identifier un user existant via un provider d’identité dument déclaré dans AUTH_PROVIDERS => la configuration de celui-ci étant utilisée pour obtenir des infos sur le token notamment sa date d’expiration. Si on parle d’un token arbitraire (i.e. non JWT = “dummy token”) ou issu d’un provider ne proposant pas de endpoint normalisé OpenIDConnect token info il faut alors implémenter le calcul des infos - notamment sa date d’expiration - de ce token dans le hook getAuthTokenInfo.
Nous avons essayer de modifier notre retour de méthode getAuthTokenInfo {“valid”:true,“expiry”:10,“login”:“test2024”}, en modifiant le expiry (non pas en temps seconde) mais avec une date d’expiration : cela nous donne toujours le même résultat
Avec des appels identiques via Postman, une fois on passe dans la méthode getAuthTokenInfo, une autre fois on est rejeté avant même d’y passer
Pour deux appels identiques et consécutifs sur Postman, nous avons deux retours différents. On a surement du rater un paramètre mais lequel ?
Je pose la question pour savoir si cela ne permet pas de déterminer sa durée de validité (comme c’est le cas avec un endpoint OpenIDConnect “token info” ou un simple parsing JWT).
Aujourd’hui pour des tests, on met 10s pour tester en mode bouchon et nous constatons un comportement alternatif. (une fois, cela fonctionne, une fois cela ne fonctionne pas).
De notre compréhension, notre Token validé est associé à une session pendant 10 s. Hors pendant ces 10 s, si on lance plusieurs appels, alors une fois le Token va être considéré expiré par le socle Simplicité et une autre fois, il va être traité par le getAuthTokenInfo alors qu’on ne devrait plus passer dans la méthode getAuthTokenInfo tant que la session associée au Token n’est pas expirée.
Afin d’éviter toute erreur, que devons-nous renvoyer dans le expiry, un temps de validité en ms ou une date de fin de validité (expiration) ?
Il y a un mécanisme de “cache” des tokens, donc une fois expiré un token n’est plus sensé être réutilisé et certainement pas “reactivé” en lui redonnant une durée de validité = je n’ai aucune idée de la manière dont ça va se comporter si on le fait…
Bref, récupérer la vraie durée de validité du token et donnez lui cette validité (après avoir fait un clear cache complet pour être sûr de ne pas avoir ce token en “zombie” expiré dans le cache)
Ce que je ne comprend toujours pas c’est : comment validez-vous CONCRETEMENT ce token ?
Je voudrais voir si vous n’êtes pas juste en train de réinventer la roue vs des mécanismes standards qui existent déjà et fonctionnent parfaitement
Le paramétrage est réalisé et fonctionnel, néanmoins nous avons implémenté la méthode getAuthTokenInfo. La prise en compte de l’expiration a réglé le problème.