-
Permettre à un utilisateur de s'authentifier via un fournisseur OpenID Connect, par exemple Keycloak, en présentant une attestation d'identité vérifiable.
-
Émettre des attestations d'identité vérifiables d'authentification aux utilisateurs qui le désirent.
-
Démontrer la possibilité d'étendre le fournisseur OpenID standard (Keycloak) afin qu'il prenne en charge l'authentification à partir d'un justificatif d'identité vérifiable.
-
Configurer une partie dépendante (relying party)(Openshift) pour utiliser cette méthode d'authentification.
Une attestation d'identité vérifiable est essentiellement un ensemble d'affirmations délivrées par une autorité de confiance que l'on nomme habituellement: "Émetteur". Ces affirmations sont faites sur un sujet (une personne, une compagnie, etc.) de telle sorte que, lorsqu'elles sont présentées à un vérificateur, leur authenticité peut être vérifiée de manière cryptographique.
OpenID Connect est un protocole d'authentification basé sur OAuth2.0. Dans une implémentation standard, une partie utilisatrice va former une demande d'authentification puis elle l'envoie à un fournisseur OpenID de confiance qui se charge d'authentifier l'utilisateur au nom de la partie utilisatrice. Le fournisseur OpenID gère et conserve les identités réelles des utilisateurs et la manière de les authentifier. Twitter, Facebook et Github sont des fournisseurs OpenID Connect parmi les plus populaires. Pour authentifier et identifier un utilisateur, le fournisseur OpenID lui demande, le plus souvent, un nom d'utilisateur et un mot de passe. Avec ces informations, il construit un jeton d'identité et le renvoie à la partie utilisatrice. Ici, la question posée par la partie utilisatrice doit être la suivante : pouvez-vous demander à cet utilisateur de présenter une attestation d'identité vérifiable qui répond à ces contraintes? Lorsque la partie utilisatrice qui se fie à l'authentification utilise cette méthode, elle peut imposer un ensemble de contraintes, dont voici quelques exemples :
- Émetteur du justificatif - Par qui a-t-il été émis?
- Schéma du justificatif - De quel type de justificatif s'agit-il ?
- Attributs du justificatif - Quelles sont les affirmations qui présentent un intérêt ?
Le résultat final pour une partie utilisatrice est le même qu'avec le flux OpenID Connect traditionnel en ce sens qu'elle obtient ce que l'on appelle un jeton d'identité, la seule différence réelle étant la manière dont ce jeton est construit. Plutôt que d'être alimenté sur la base des informations de l'utilisateur détenues par le fournisseur OpenID, il est construit en utilisant les affirmations dans l'attestation d'identité vérifiable que l'utilisateur présente.
Voir les instructions de déploiment sur OpenShift.
-
Un (1) portefeuille numérique appartenant à l'utilisateur est disponible, sur lequel son attestation d'identité vérifiable est émise;
-
Un répertoire distribué identitaire se conformant au framework ARIES est en place et permet d'émettre des attestations ainsi que les schémas associés;
-
Un émetteur d'attestation représentant l'organisme qui octroie l'accès est en place;
-
Un consommateur d'attestation est en place à travers le service d'authentification représenté par le fournisseur d'identité;
-
Une vérification d'identité n'est pas requise pour émettre l'attestation d'identité dans la démo;
-
Les notifications et publications entre les intervenants ne sont pas dans la portée de l'expérimentation. On assume qu'elles sont exécutées de manière appropriée lorsque mentionnées;
-
L'organisme émetteur consigne la relation entre l'utilisateur et son organisme dans le répertoire d'accès.
Voici l'architecture des composants nécessaires à haut niveau pour émettre une attestation d'identité vérifiable à un utilisateur.
Émission de l'attestation d'identité vérifiable à l'utilisateur
Voici l'architecture des composants nécessaires à haut niveau pour consommer l'attestation d'identité vérifiable d'un utilisateur via une authentification OpenID Connect.
Consommation de l'attestation d'identité vérifiable via une authentification OpenID Connect
-
Effectuer le déploiment sur OpenShift.
-
Installer le portefeuille d'identité numérique esatus sur un téléphone mobile.
-
Sélectionner le réseau vonx.pocquebec.
-
Accéder à l'application d'émission.
-
Saisir les informations demandées.
-
Cliquer sur le bouton "Émettre attestation".
-
Scanner le code QR avec le portefeuille d'identité numérique.
-
Dans la fenêtre de dialogue "vc-authn-agent - wants to connect with you", cliquer sur "Connect" et ensuite sur "Close".
-
Dans la fenêtre de dialogue "New Credential - You've got a new Credential Offer from vc-authn-agent", cliquer sur "View Offer" et ensuite sur "Close".
-
Accepter l'attestation.
-
Accéder à la console Openshift.
-
Sur la page "Log in with...", cliquer sur "openid".
-
Sur la page "OPENSHIFT Log In", cliquer sur "Verifiable Credential".
-
Scanner le code QR avec le portefeuille d'identité Esatus.
-
Sur la fenêtre "New Request", cliquer sur "View Request".
-
Sur la page "Basic Proof", cliquer sur "Send".
- Sur la fenêtre "Sending successful", cliquer sur "Finish".
Voici le schéma de données utilisé pour l'attestation d'identité numérique ainsi que pour sa délégation: Schema name: CQEN_AUTHENTICATION Schema version: 1.0
{
"schema_name": "CQEN_AUTHENTICATION",
"schema_version": "1.0",
"attributes": [
"first_name",
"email",
"username",
"last_name"
]
}Par exemple, l'attestation d'identité d'authentification pourrait être composée des valeurs suivantes:
| Nom de l'attribut | Valeurs |
|---|---|
| username | user01 |
| prenom.nom@sct.gouv.qc.ca | |
| first_name | Prénom |
| last_name | Nom |
Tableau 1 - Données de l'attestation d'identité d'authentification
Après l'émission d'un justificatif d'identité vérifiable dans le portefeuille d'identité numérique, il a été possible de s'authentifier sur le cluster Openshift sans saisir d'usager/mot de passe.
Le but de l'expérience était de démontrer qu'il est possible d'étendre le fournisseur OpenID standard Keycloak afin qu'il prenne en charge l'authentification à partir d'une attestation vérifiable. En utilisant le Keycloak configuré pour sécuriser l'accès à notre cluster Openshift, il a été possible de s'authentifier à partir d'une attestation vérifiable émise dans le portefeuille d'identité Esatus.
Afin de réduire le risque d'accès frauduleux, il est important d'accorder une attention particulière à la sécurité des composantes mises en place. L'application émettrice d'attestion doit être accessible uniquement par un minimum de personnse. Elle doit être protégée au minimum par un usager/mot de passe. Dans cette expérimentation, étant donné que le Keycloak offrait déjà l'authentification par Active Directory (AD), il a été paramétré pour forcer la présence d'un compte avec le même nom d'usager dans l'Active Directory lors de l'authentification par attestation vérifiable. Il serait également pertinent de sécuriser l'accès à l'url de l'application émétrice à un usager préalablement authentifié sur le cluster Openshift.
L'authentification par attestation vérifiable via un fournisseur OpenID standard est tout à fait possible et elle a été clairement démontrée lors de cette expérience. Cette méthode d'authentification offre la possibilité de mettre en place un environmenet dans lequel l'usager n'a plus à saisir de mot de passe (et n'a plus à les renouveler).
Distribué sous Licence Libre du Québec – Réciprocité (LiLiQ-R). Voir LICENCE pour plus d'informations.