WO2 Identity Server 5.10.0, Carbon 4.6.0 — Nouveautés WSO2 mars 2020 [1/2]

L’amélioration de l’expérience utilisateur et de la sécurité sont au cœur des nouveaux développements de l’éditeur WSO2

WSO2 Carbon 4.6.0

La framework Carbon passe en 4.6.0. Mais pourquoi une nouvelle version si rapidement après la 4.5? Tout simplement car le système de gestion des utilisateurs au cœur même de la framework commençait à devenir problématique.

Jusqu’à présent l’identifiant unique des utilisateurs étaient leur nom d’utilisateur ce qui entraînait de nombreuses limitations et complexités du système. Par exemple, comment changer le username d’une personne? comment s’authentifier autrement que par le username? Jusqu’à présent c’était tout bonnement impossible sans rustine! Avec cette modification ce type de besoin va enfin pouvoir avoir une réponse propre et native dans le futur.

WSO2 en a profité pour ré-écrire l’ensemble de ces connecteurs aux annuaires et faire quelques améliorations comme l’activation par défaut de SCIM2 ou la possibilité de limiter le nombre d’utilisateurs retournées par une requête.

WSO2 Identity Server 5.10.0

Enfin un renouveau des interfaces utilisateurs pour ce produit! Cette version 5.10 apporte une nouvelle interface pour les pages d’authentification, de création de compte et de récupération, plus facilement personnalisable et entièrement localisable.

Le dashboard utilisateur tire sa révérence au profit d’un portail utilisateur complètement revu et repensé au standard du marché. Il a été construit en TypeScript et utilise la framework front React. Les composants sont facilement activables ou non, sont style est extensible et il est localisable.

Ce nouveau portail utilisateur exploite de nouvelles APIs REST JSON pour vous faire bénéficier de nombreuses fonctionnalités regroupés en 3 thématiques :

• Information Personnelle : gestion de son profil, association de comptes locaux ou fédérés, export des ses données personnelles et consentements
• Sécurité : changement de mot de passe, gestion de ses options de recouvrement, configuration de son facteur TOTP, FIDO, SMS, gestion de ses sessions actives et de ses consentements
• Opérations : gestion des demandes d’approbations

Et petite surprise une nouvelle fonctionnalité fait son apparition avec la possibilité pour un utilisateur de consulter un annuaire des applications disponibles.

Il vous suffira de configurer la visibilité et de fournir les informations nécessaire dans la configuration de votre service provide:

Et ce n’est pas fini, les travaux autour du nouveau portail développeur, qui remplacera à terme l’interface Carbon, ont déjà commencés et devrait être de la partie dans la version 5.11.0.

Oauth2 account switch flow

Il est maintenant possible de switcher entre les comptes que vous avez associés dans le User Portal avec un simple appel Oauth2/OpenId Connect.

Pour ce faire il vous suffit d’activer le grant type account_switch et de réaliser la requête suivante:

curl -X POST \
  https://localhost:9443/oauth2/token \
  -H 'Authorization: Basic {base64(client_id:secret)}' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'cache-control: no-cache' \
  -d 'grant_type=account_switch&username={username}&userstore-domain={usernameUserstore}&tenant-domain={usernameTenant}&token={currentAccessToken}&scope=openid'

Oauth2 device flow

WSO2 ajoute à son produit l’implémentation du grant type Device Authorization issue d’une toute nouvelle spécification standardisée en août 2019 la RFC8628 (https://tools.ietf.org/html/rfc8628).

Ce flow vise à apporter une solution pour transmettre une authorization à des applications dépourvues de navigateur ou ayant une interface de saisie très limité voire inexistante.

Le cas typique c’est une application de smart TV. Qui ne s’est jamais étranglé en tentant d’entrer son mot de passe à partir de sa télécommande?

Plus concrètement, quand un utilisateur souhaite se connecter, l’application cliente contacte le serveur d’autorisation, et obtient en réponse un code de vérification pour lui, un code et une url de vérification à afficher à l’utilisateur. Un QR code s’affiche à l’écran. L’utilisateur utilise ces informations pour donner son autorisation à partir de son mobile ou de son ordinateur. L’application contacte toutes les 5 secondes le serveur d’autorisation avec son code de vérification tant que celui-ci est non expiré pour savoir si l’utilisateur l’a autorisé. Si c’est le cas il recevra un access token et optionnellement un refresh token. Et voila!

Client-Initiated Back-channel Authentication (CIBA)

Pour faire simple CIBA c’est la spécification OpenId Connect de l’Oauth2 Device flow. Tous les flows hors CIBA sont désignés comme étant Redirected car basés sur l’usage de redirections dans un navigateur, les flows CIBA sont eux désignés comme étant Decoupled car basés sur un découplage du client et de l’interface de saisie de l’autorisation.

La spécification CIBA a été pensée avec 3 modes de réception des tokens:

• Pull: le client pull à intervalle régulier le serveur d’autorisation (comme le device flow oauth2)
• Notify: le serveur d’autorisation notifie le client qu’il peut venir chercher les tokens
• Push: le serveur d’autorisation envoi les tokens aux clients dès qu’ils sont disponibles

La spécification CIBA est encore en draft (https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) mais bientôt stable. Les travaux sont coordonnés avec le working groupe FAPI qui vise à fournir des spécifications communes de sécurisation d’APIs financières à travers le monde.

WebAuthn

WebAuthn est une nouvelle recommandation du W3C réalisé en collaboration avec l’alliance FIDO. (https://www.w3.org/TR/webauthn/)

Elle définie une nouvelle interface d’authentification web pour les utilisateurs basée sur l’échange de clés asymétriques.

Le principe est simple, quand vous arrivez sur la page de connexion un script javascript va se déclencher et vous demander de vous authentifier depuis votre ordinateur, soit directement sur celui-ci soit via un dispositif externe. Une fois cette opération réalisée le navigateur va signer avec sa clé privée un message et l’adresser au serveur d’authentification. Celui-ci va valider le message avec la clé publique correspondante préalablement enregistré puis créer la session.

Les paires de clés sont propres à chaque relation et généré à l’enregistrement ce qui garantie qu’une corruption d’un parti n’impactera pas les autres.

Le serveur d’authentification ne connait plus que la clé publique de l’utilisateur et ne stocke donc plus lui-même les données d’authentification de l’utilisateur ce qui renforce grandement la sécurité du système.

WebAuthn est actuellement supporté par Chrome ≥ 67, Firefox ≥ 60, Edge ≥ 17723.

Et bien sûr cette nouvelle version contient beaucoup de patchs et petites améliorations comme la possibilité de configurer son serveur SMTP par tenant.

Oauth2 token binding

vous avez maintenant la possibilité de configurer à quoi vos tokens Oauth2 sont liés. Soit à un cookie déposé dans le navigateur soit à la session SSO de l’utilisateur.

Et petite dernière pour la route, vos utilisateurs n’auront plus à donner des consentements à un nom d’application technique! La contrainte sur la syntaxe des noms des services providers a été levée. Il vous ait maintenant possible de mettre des espaces, points, traits d’union et underscores.