2023-08-23 14:01:07,430|SIMPLICITE|ERROR||http://siparex-simplicite-dev-5b48c75c56-plwhn:8080||ERROR|system|com.simplicite.webapp.servlets.OAuth2Servlet|doGet||Event: AADSTS50146: This application is required to be configured with an application-specific signing key. It is either not configured with one, or the key has expired or is not yet valid.
Trace ID: 37ccc01a-fc88-4162-abcc-4bdcfe803900
Correlation ID: d65552e8-893a-4bf1-a949-5e76ccfa9903
Timestamp: 2023-08-23 12:01:07Z
com.simplicite.util.exceptions.AuthenticationException: AADSTS50146: This application is required to be configured with an application-specific signing key. It is either not configured with one, or the key has expired or is not yet valid.
Trace ID: 37ccc01a-fc88-4162-abcc-4bdcfe803900
Correlation ID: d65552e8-893a-4bf1-a949-5e76ccfa9903
Timestamp: 2023-08-23 12:01:07Z
at com.simplicite.webapp.servlets.OAuth2Servlet.callback(OAuth2Servlet.java:921)
at com.simplicite.webapp.servlets.OAuth2Servlet.doGet(OAuth2Servlet.java:1120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:529)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:623)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:209)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
at com.simplicite.webapp.filters.HTTPHeadersFilter.doFilter(HTTPHeadersFilter.java:39)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:49)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
C’est un problème d’intégration avec l’AD, en 5.3 il y a eu des évolutions mais le fonctionnement nominal du protocole OAUTH2 reste inchangé, et la classe Simplicité MicrosoftAPITool n’a pas évoluée non plus (les requêtes vers l’AD).
Il faut traiter l’erreur AADSTS50146 en cherchant sur le web ses causes possibles.
comme autoriser l’email comme alternative d’identification
et autoriser le acceptMappedClaims = true
Et comparer vos requêtes HTTP entre la dev et la prod AD.
Il y a eu des évolutions sur les token JWT mais je suis pas l’expert du sujet. @david pourra surement aider mais il est en congé jusqu’à la fin du mois.
Nous avons pris un moment de debuggage avec Yannis (Datailor).
Nous sommes retombés sur les mêmes résultats que @daniel sur l’instance de production.
Il s’avère que le mapping (au vu de la configuration de l’application d’entreprise sur le portail Azure) n’accepte plus que login = upn.
Cependant l’upn n’est pas déchiffrer par Simplicité et renvoie un code bizarre de ce type : .
Attendons le retour de david, puis on organisera un point avec Daniel, David et Yannis pour qu’ils puissent enquêter tous ensemble.
La seule “nouveauté” en 5.3 vs la 5.2 sur l’authent OpenIDConnect c’est le check du “nonce” du token JWT, ce qui peut être inhibé en mettant explicitement "jwt_check_nonce": false dans les settings. Si votre pb vient de là vous devez avoir un message explicite dans les logs (Missing nonce in token ou Inconsistent nonce in token ou Unable to check nonce for provider <nom du provider>.)
Sinon pour analyser plus finement il faudrait activer le log event DAUTHSC001 pour avoir plus d’info dans les logs sur ce qui est échangé entre Simplicité et Azure AD.
Notamment pour voir ce qui est de votre mapping destiné à retrouver le login applicatif à partir des user infos ou des claims JWT. Dans votre configuration vous mappez l’adresse email des user infos, si celle-ci n’est plus présente dans les user infos Azure AD ça ne marchera plus avec votre configuration actuelle et il faudra déterminer quel nouveau mapping serait approprié.
PS: Au delà d’un simple mapping comme ci-dessus, s’il y a besoin d’une logique spécifique pour déterminer le login applicatif à partir de données issues de la séquence d’authentification ça peut toujours s’implémenter dans le platform hook parseAuth
Merci pour votre réponse, je fais le point en interne avec notre admin 365 et je vous tiens au courant.
Nous ne souhaitons pas coder via la plateform hook afin de limiter notre maintenance en code.
Dans la tous les cas de configuration Azure AD dont j’ai connaissance un simple mapping sur un claim du token JWT ou une donnée retournée par le endpoint user info suffit.
Mais s’il n’y a aucune donnée de ce type qui matche directement avec le login applicatif (et que par exemple vous devez faire un appel additionnel à une autre API Microsoft pour avoir l’info d’identification ad hoc) vous n’aurez pas le choix, vous devrez coder cette logique spécifique.
Bonjour David, Je continue sur la demande d’Ophélie car nous travaillons ensemble sur le sujet.
Nous avons évolué dans le bon sens depuis la publication de cette demande, l’authentification à l’air maintenant de fonctionner, mais l’utilisateur n’est pas reconnu convenablement.
Nous mappons le login de l’utilisateur en provenance d’Azure sur la base de son UPN
Mais au lieu d’être reconnu comme “de.admin@…” il est reconnu avec une suite aléatoire de type :
_bM8-PbDWdDIxWXvUp5VeCKSJkdK8UwVqlzVbaP4Nl8
Et forcément ca ne matche pas l’utilisateur sous simplicité, ci dessous les logs générés :
2023-09-07 13:46:53,278|SIMPLICITE|ERROR||http://siparex-simplicite-dev-5b48c75c56-bqrgj:8080||ERROR|system|com.simplicite.util.SessionInfo|syncUser||Event: Unable to update user _bM8-PbDWdDIxWXvUp5VeCKSJkdK8UwVqlzVbaP4Nl8: ERR_LICENSE_4
2023-09-07 13:46:53,270|SIMPLICITE|WARN||http://siparex-simplicite-dev-5b48c75c56-bqrgj:8080||WCORED0001|system|com.simplicite.util.engine.ObjectManager|completeForeignKeys||Warning: REF_NOT_FOUND: Unable to find reference usr_home_id of object User
Comment faire en sorte que l’upn présent dans le token soit récupéré correctement par simplicité ?
Le upn est un identifiant technique non signifiant et non stable dans le temps, il ne peut donc pas être mappé sur le login applicatif qui est, lui, forcément de nature métier = signifiant et stable dans le temps (i.e. un email, un username, …)
Comme dit précédemment il faut donc chercher dans la réponse du endpoint userinfo de votre IdP ou dans les claims du token JWT renvoyé par votre IdP (ou autre mécanisme spécifique: ex: appel API de l’IdP) l’élément identifiant métier qui pourra correspondre à votre login applicatif.
Et comme dit aussi plus haut, pour avoir plus détails sur les données échangéess entre l’application et votre IdP (typiquement pour voir la réponse du endpoint userinfo), il faut activer le log event DAUTHSC001. Sans cela vous êtes en aveugle et vous ne pourrez pas trouver le mapping adapté à votre cas.
Pour voir les traces associées au log event DAUTHSC001 sans monter globalement le niveau de trace à debug (ce qui générerait beaucoup trop de traces) il faut passer le niveau à “Info” de ce log event + faire un rechargement des log events:
Dans l’exemple ci-dessus le mapping du login se fait sur l’attribut “email” reçu en réponse à l’appel du endpoint user info de l’dP (NB: il existe aussi un mécanisme de mapping permettant d’utiliser un attribut “claim” du token JWT en lieu et place d’un attribut du user info)
Dans la réponse il y a visiblement une adresse email (attribut email), celle-ci étant sensée être unique elle pourrait servir de login métier (c’est souvent le cas).
Auquel ca il faut mettre "userinfo_mappings": { "login": "email" } dans la définition du provider et s’assurer que les logins matchent bien - casse comprise - avec ces emails renvoyés dans le user info.
Sinon il faut trouver quel autre attribut du user info pourrait mapper sur le login (la trace fournie en copie d’écran est incomplète on ne voit pas l’intégralité du user info).
PS: L’autre approche de mapping du login (exclusive vs le user info) c’est avec un claim du token JWT, là aussi il faut savoir quels sont les claims présents dans les tokens générés par votre IdP pour trouver lequel mapper.
Notre cas est différent, on souhaite ne pas se mapper via l’adresse email mais sur le nom d’utilisateur principal. En effet nous avons des noms de domaines différents exceptés pour ce nom d’utilisateur principal. Cela génère des exceptions sur la génération de login sauf si on se base sur ce “userprincipalname”.
Visiblement le “userinfo” ne permet pas de remonter cette information qui semble pourtant + cohérente que l’email.
Le problème n’est pas résolu mais il semble qu’il n’y ait pas de solution.
merci
Sans les traces DAUTHSC001 (notamment celles de la réponse du userinfo) c’est compliqué de vous aider mais si je comprends ce que vous dites cette config devrait fonctionner :
Moyennant, bien sûr, que cet attribut userprincipalname matche exactement (casse comprise) avec le login d’un utilisateur déclaré au niveau applicatif (c’est la fonction de ce mapping = retrouver le login)
S’il y a un pré-traitement à faire sur cet attribut pour l’'aider à matcher exactement (ex: le forcer en minuscules) ça peut s’implémenter dans le platform hook parseAuth
PS: il n’y a pas que le userinfo où on peut chercher à mapper un attribut qui matche avec le login, on peut aussi mapper un claim du token JWT
.
