WSO2 Identity Server 6.0.0

Cette nouvelle version cache bien son jeu. Elle apporte de nombreuses fonctionnalités liées au développement de l’offre CIAM de l’éditeur.

C’est la rentrée, nous allons vous parler de la nouvelle version de WSO2 Identity Server sortie le 16 août dernier. Vous verrez que même si vous avez lu la release note de l’éditeur vous aller découvrir plein de nouvelles choses !

Support de Java 17

Le support de Java 11 s’arrêtant en septembre 2023, WSO2 ajoute le support de Java 17, qui lui se terminera en septembre 2026.

Quand à Java 8 il n’est plus officiellement supporté.

Intégration avec ELK

WSO2 continue sa démarche de retrait de ses composants analytics au profit de solutions externes. Ainsi WSO2 IS Analytics va être déprécié et remplacé par une intégration avec la suite ELK.

Le fonctionnement est classique, un handler écrit des évènements dans un fichier que Filebeat transfère. Logstash s’occupe ensuite de les rafiner et de les indexer dans ElasticSearch. Kibana présente ensuite les données dans des dashboards personnalisés.

WSO2 a migré à l’identique le fonctionnement, vous retrouverez un dashboard de suivi des authentifications, un autre concernant les sessions et la ré-implémentation des alertes.

Concernant la partie analyse de risque, l’éditeur ajoute une fonction utilisable dans vos scripts adaptifs utilisant le nombre de résultats comme score de risque.

L’éditeur ne fournit toujours pas de template d’analyse de menace standard, ce qui est bien dommage !

Nouveaux standards OAuth2

OAuth2 Device Flow

WSO2 ajoute le support de la RFC 8628 qui permet de faciliter l’authentification sur des appareils n’ayant pas d’interface de saisie, comme une télévision, en déléguant celle-ci à un équipement tiers (téléphone, ordinateur).

A noter que l’éditeur avait déjà réalisé une première implémentation de ce flow au sein de WSO2 IS 5.10.0 avant de la retirer.

OAuth2 DPoP (draft)

Demonstrating Proof-of-Possession at the Application Layer est un draft de standard de l’IETF visant à sécuriser l’usage de jetons OAuth2 en demandant à l’application qui l’utilise de prouver qu’elle en est le propriétaire.

WSO2 implémente cette draft de manière non officiel. Il vous faudra télécharger une extension et la configurer pour que cette fonctionnalité soit utilisable.

Pour plus d’information :

• Billet de blog montrant sa mise en œuvre
• Code source

Ajout de nouveaux facteurs d’authentification

Magic Links

Le principe du magic links est trés simple, vous vous identifiez, vous recevez un mail et en cliquant sur le lien contenu dans celui-ci vous êtes directement connecté.

Ajout de systèmes d’authentification externes

WSO2 a ajouté des connecteurs à des services externes :

• TypingDNA: facteur d’authentification comportemental analysant la manière d’écrire.

• UAEPass: authentification avec l’application gouvernementale des Émirats Arabes Unis

Support de ReCaptcha v3

WSO2 a ajouté le support de la v3 de ReCaptcha permettant de recevoir un score de risque et de laisser libre son interprétation.

L’éditeur a également a ajouté le mode invisible de l’api v2.

Amélioration de l’authentification adaptive

Pourquoi l’authentification adaptive est désactivée par défaut si vous utilisez Java 17 ?

L’implémentation du language de script repose sur le moteur Javascript Nashorn introduit au sein de Java 8. Sa maintenance est depuis compliquée et des alternatives sont apparues tel que GraalJs. Il a donc été décidé de ne plus l’embarquer dans OpenJDK à partir de la version 14.

Le moteur Nashorn est maintenant disponible en tant que librairie externe. WSO2 a fait le choix de désactiver par défaut la fonctionnalité et de fournir un script bin/adaptive.sh|bat qu’il suffit de lancer pour télécharger les librairies Nashorn et ASM et réactiver la fonctionnalité.

Pour en savoir plus : https://github.com/openjdk/nashorn

Nouvelle Interface de configuration du workflow d’authentification

WSO2 a souhaité refondre une nouvelle fois l’interface de configuration des facteurs d’authentification au sein de la nouvelle console d’administration pour la rendre plus lisible.

Un premier écran vous proposera de configurer votre workflow selon des templates pré-établis :

Ensuite une nouvelle vue vous présentera votre flux d’authentification de manière verticale :

Ajout de fonctions au sein du langage de script adaptif

L’éditeur a ajouté :

• une fonction callChoreo pour envoyer une requête au nouveau service DPaaS Choreo de l’éditeur.
• les fonctions pour communiquer avec ELK.

API de gestion des secrets

Une nouvelle API pour gérer des secrets fait son apparition. Celle-ci, comme toutes les nouvelles APIs, est compatible avec un usage en mode multi-tenant. Elle va permettre de sécuriser le stockage d’informations sensibles au sein de l’Identity Server comme des informations de connexion à des services tiers.

Voir son contrat d’API.

A noter que son usage est pour le moment limité à sa gestion et qu’il faut que la fonction adaptive l’implémente en son sein. Il n’existe notamment pas de syntaxe de variable pour l’utiliser directement au sein d’un script adaptif. Seule la fonction callChoreo semble l’employer pour le moment.

Support de l’algorithme PBKDF2

Password Based key Derivation Function2 est un algorithme de hachage moderne défini au sein de la RFC 2898. Il est notamment requis pour respecter la norme FIPS-140–2 du NIST.

key = PBKDF2(password, salt, iterations-count, hash-function, dkLen)

WSO2 a profité de cet ajout pour modulariser la gestion des algorithmes de hachage de mot de passe permettant d’ajouter simplement le support d’un nouvel algorithme sans avoir à surcharger un UserStoreAdapter :

• Interface de service de hash
• Exemple d’implémentation

On regrettera que l’éditeur n’ait implémenté que cet algorithme dont l’usage commence à être controversé (sensible au calcul parallèle avec GPU). On aurait voulu voir également BCrypt, SCrypt, Aragon2d, Aragon2i, Aragon2id.

Amélioration du Just-in-Time Provisioning

WSO2 a ajouté un mode avancé à la fonctionnalité de provisionnement automatique lors de l’authentification à un IdP tiers.

Chaque utilisateur provisionné de cette manière verra un nouveau claim http://wso2.org/claims/identity/userSourceId provisionné avec l’identifiant de l’IdP source ainsi que son username renseigné avec un identifiant d’utilisateur fédéré unique. Ces attributs vont permettre :

• De rendre possible l’usage d’un second facteur local tel que TOTP ou Email OTP
• De permettre de verouiller un compte provisionné de cette manière
• Quand l’IdP est supprimé l’ensemble de ses utilisateurs provisionnés localement le seront également (pas le compte local associé si vous lui avez demandé de créer un identifiant et un mot de passe local)

Comme il s’agit d’un utilisateur tiers l’ensemble de ses attributs seront en lecture seule.

Pour l’activer :

[authentication.jit_provisioning] 
enable_enhanced_feature = "true"

Amélioration de l’implémentation SCIM2

Nom de schéma personnalisé

WSO2 permet à présent de remplacer le schéma EnterpriseUser par son propre nom de schéma.

Nos tests ont été peu concluants sur ce point et nous regrettons le non-support de schémas multiples personnalisés et le fait que les attributs d’identités spécifiques à WSO2 ne sont toujours pas isolés dans leur propre schéma.

Ajout d’opérations de filtre

L’éditeur a ajouté le support des opérateurs GE, LE, GT, LT, NE.

Nous attendons toujours désespérément l’opérateur OR qui permettrait de simplifier nombre de nos requêtes !

L’éditeur à également introduit de nombreux correctifs et amélioration de performance bienvenue.

L’usage des APIs SCIM2 dans les nouvelles interfaces graphiques de l’éditeur a permis que celui-ci se rende compte des problèmes existants, mais le chemin est encore long pour résoudre toutes les imperfections de l’implémentation actuelle que nous avons listé dans notre précédent article : SCIM 2.0 : Usage avec WSO2 Identity Server [2/2]

Analyses et contremesures au blocage des cookies tiers

Depuis plusieurs années, les éditeurs de navigateurs web luttent pour améliorer la confidentialité de la navigation. L’un de leurs axes majeurs est le blocage progressif de l’intégralité des cookies tiers. Malheureusement, les flux d’authentifications et d’autorisations reposent essentiellement sur cette mécanique pour fonctionner. En attendant qu’une solution pérenne soit fournie par ces derniers, des contournements doivent être trouvés pour limiter l’impact de ces choix.

Vous trouverez dans l’article The Impact of Blocked Third-Party Cookies on WSO2 Identity Server les conclusions de l’analyse de WSO2 rattaché au ticket #10979.

WSO2 a travaillé sur plusieurs améliorations qui sont intégrées nativement à WSO2 IS 6.0.0.

Ajout de l’attribut SameSite sur les différents cookies utilisés dans les produits WSO2

En mars 2020, WSO2 a réalisé un patch pour ajouter une valve tomcat qui ajoute l’attribut SameSite sur l’ensemble des cookies générés. Ce patch a été mis à disposition pour toutes les versions du produit à partir de la version 5.2 de l’Identity Server.

[catalina.valves.valve.properties]
className = "org.wso2.carbon.tomcat.ext.valves.SameSiteCookieValve"

Pour plus d’information je vous conseille de lire l’article: SameSite Attribute Support in WSO2 Products

Retrait de la dépendance aux cookies pour étendre la session de l’IdP

Jusqu’à présent, l’identifiant de session était transmis à travers le cookie commonAuthId. WSO2 a ajouté un attribut “isk” (IdP Session Key) au sein des access tokens OAuth2, des ID tokens OIDC et des assertions SAML2 contenant un hash de ce même identifiant.

L’éditeur a également introduit une nouvelle API REST pour étendre une session à partir du cookie commonAuthId ou de la valeur de l’attribut isk.

D’autres pistes sont en cours d’études :

• l’usage de cookies Fisrt party initié par WICG — voir la spécification
• l’usage du Storage Access API initié par le W3C — voir la spécification

Ajout et amélioration des politiques de l’IdP résident

Unicité de la valeur d’un claim

Il n’était jusqu’à présent pas possible de s’assurer nativement de l’unicité de la valeur d’un claim autre que l’identifiant technique et le username.

WSO2 a ajouté un intercepteur au sein du framework évènementiel interne pour réaliser ce contrôle.

org.wso2.carbon.identity.unique.claim.mgt.listener.UniqueClaimUserOperationEventListener

Pour le rendre opérationnel, il suffira ensuite de déclarer le claim concerné comme unique en ajoutant une propriété additionnelle isUnique à sa définition :

Le claim ainsi défini restera unique vis-à-vis de l’ensemble des user stores tant que la mise à jour de ces derniers n’est réalisé qu’à travers WSO2 IS.

Voir la documentation.

Identification par de multiples attributs

WSO2 rend enfin possible la possibilité de s’identifier avec un attribut autre que le username. Vous pouvez maintenant définir une liste de claims qui pourront servir d’identifiant lors du processus d’authentification.

org.wso2.carbon.identity.unique.claim.mgt.listener.UniqueClaimUserOperationEventListener

La première étape consite à rendre ces claims unique avec la fonctionnalité précédement décrite. Si la valeur d’un claim n’est pas unique l’authentification ne pourra avoir lieu.

La deuxième requiert l’ajout d’une expression régulière à la définition de chaque claim permettant à l’Identity Server de sélectionner le bon claim.

La troisième nécessite la définition de la liste des claims pouvant servir d’identifiant :

Il ne vous reste plus qu’à essayer :

Attention, il existe une subtilité facheuse concernant les emails. Le caractère @ étant le séparateur avec le nom des tenants, il est nécessaire d’ajouter explicitement celui-ci quand on saisi une adresse mail (Ex: john@wso2.com@carbon.super) Mais pourquoi WSO2 n’a pas réglé cela? Cette exigence est désastreuse en terme d’expérience utilisateur.

Amélioration des processus d’inscription et de recouvrement de mot de passe

4 améliorations ont été introduites :

1/ Si un utilisateur tente de se connecter alors qu’il n’a pas validé son adresse mail, un encart lui proposera de lui renvoyer l’email de confirmation (template d’email, ResendAccountConfirmation)

Une amélioration du système que l’éditeur pourrait envisager est de permettre de re-saisir l’email de confirmation ou de supprimer les comptes non validés au bout d’un certain temps pour éviter au maximum la création de comptes zombies.

2/ L’authentification automatique de l’utilisateur à la confirmation de son adresse ou de changement de mot de passe, qui permet à celui-ci d’éviter de ressaisir ses informations d’authentification. Il vous faudra pour cela activer la fonctionnalité au sein de la politique de Self-registration ou de Password Recovery :

3/ Le format d’OTP SMS de validation et de changement de mot de passe est maintenant configurable pour laisser à chacun le choix de la balance entre sécurité et expérience utilisateur:

4/ Les emails de recouvrement de mot de passe sont maintenant tolérants à de multiples demandes pour gérer notamment les situations ou un email ou un sms met trop de temps a être receptionné.

Vous pourrez maintenant configurer un temps de tolérance durant lequel le même code de confirmation sera expédié permettant d’éviter ce scénario :

[identity_mgt.password_reset_email]
confirmation_code_tolerance_period = 5
[identity_mgt.notification_channel_recovery]
recovery_code_validity=10
[identity_mgt.resend_notification]
resend_code_validity=15

Cette fonctionnalité a été backportée à partir de la 5.10 dans un patch fourni pas l’éditeur à travers son support.

Autres modifications d’importance

Multiple Authentication Context Classes pour un IdP SAML

Jusqu’à présent, il n’était pas possible de spécifier plusieurs classes de contexte d’authentification lors d’une fédération SAML2 ce qui pouvait entrainer l’échec de celle-ci quand un contrôle exact de cette liste était demandée. Cette limitation est maintenant dernière nous.

Validation des attestations FIDO

FIDO vous permet de vous authentifier à travers un équipement tel qu’une clé usb ou un lecteur d’empreinte. Mais qu’est ce qui garantie que l’équipement est sûr?

Il vous est maintenant possible de valider les équipements autorisés durant leur enregistrement. Une attestation, qui est une clé installé au sein de l’équipement par son fabricant, est présenté lors de la demande d’enregistrement. Il vous est ensuite possible de la comparer à un serveur de metadata FIDO référençant les appareils autorisés.

Déconnexion OIDC fédérée

Vous connaissez le principe du backchannel-logout? Et bien c’est ce principe appliqué à une fédération. Si vous vous déconnectez de l’IdP OIDC tiers, la notification de logout est remontée à WSO2 IS qui lui même va l’appliquer à sa session locale et déclancher un backchannel logout aux applications référencées.

WSO2 Private CIAM Cloud

En parallèle de la sortie de WSO2 Identity Server 6.0.0, WSO2 a dévoilé la création de WSO2 Private CIAM Cloud.

C’est une version spéciale de l’IS 6.0 dans laquelle l’éditeur a ajouté la gestion d’une hierarchie d’organisation permettant de déléguer l’administration des droits des utilisateurs et de moduler les politiques d’accès.

Nous n’en savons pas beaucoup plus pour le moment mais nous espérons que ces fonctionnalités seront disponibles on-premise dans le futur, car elles réponderaient à de nombreux besoins aussi bien de gestion client que de gestion du personnel.

C’est tout pour ajourd’hui, à bientôt!