OpenId Connect — Comment une application peut imposer un niveau de sécurité ? [3/3]

Une application, compatible OpenId Connect, dite sensible peut vouloir s’assurer qu’une authentification réalisée par un serveur d’authentification respecte ses besoins en termes de degré de confiance concernant la personne qui va utiliser ses services.

Cette série, “Comment une application peut imposer un niveau de sécurité ?” est composée de 3 parties :

1. LoA — Level of Assurance

2. SAML 2.0 AuthnContext

3. OpenID Connect ACR

Je vous invite dans un premier temps à relire ce qu’est un contexte d’autorisation dans le précédent article de la série.

Que fourni le standard OpenId Connect?

La notion de contexte est défini au cœur de la spécification dans le document OpenId Connect 1.0 Core.

ID Token

Dans sa section 2 consacrée à la définition de l’ID Token la spécification introduit 3 termes:

• ACR : Access Context Class Reference
  Contient une URI absolu ou un profile LoA, comme défini dans la RFC 6711, définissant le contexte métier de l’authentification courante. “0” signifie que l’authentification ne respecte pas les prés-requis minimum de sécurité pour accéder à des ressources sécurisées (cookie longue durée par exemple)
• AMR : Authentication Methods References
  Liste des facteurs d’authentification mis en oeuvre pour cette session.
• AZP : Authorized Party
  Contient le client_id du destinataire de l’autorisation (si non présent utiliser la valeur d’audience AUD)

Pour résumer l’ID Token généré pour la session d’authentification OpenId Connect courante à destination de AZP à atteint le niveau d’assurance ACR en utilisant les facteurs d’authentification AMR.

Pour tenter de normaliser les valeurs du champ AMR la RFC 8176 sorti en 2017 établi un registre initial de valeurs pouvant être utilisé :

• face : reconnaissance faciale
• fpt : reconnaissance par empreinte digitale
• geo : géolocalisation
• hwk : preuve de possession d’une clé physique
• iris : reconnaissance par l’iris
• kba : base de connaissances
• mca : authentification via canaux multiples
• mfa : authentification multi-facteurs
• otp : mot de passe à usage unique
• pin : Numéro d’authentification personnel
• pwd : mot de passe
• rba : authentification par évaluation des risques
• retina : reconnaissance par empreinte rétinienne
• sc : carte à puce
• sms : confirmation par sms
• swk : preuve de possession d’une clé logicielle
• tel : confirmation par téléphone
• user : confirmation de la présence de l’utilisateur
• vbm : authentification par reconnaissance vocale
• wia : authentification intégrée windows

Requête d'authentification

Nous venons d’apprendre comment est décrit le contexte d’authentification de la session courante mais au fait comment demande-t-on un contexte spécifique?

Rien de plus simple il vous suffit d’ajouter le paramètre acr_values dans votre requête d’authentification. Celui-ci doit contenir une liste ordonnée par préférence et séparée par des espaces des contextes d’authentification souhaités.

Exemple de requête d’authentification :

GET /authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &acr_values=urn%3Acom%3Aexemple%3Aserver%3Amfa HTTP/1.1
  Host: server.example.com

Exemple d’ID token envoyé en réponse:

{
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:com:exemple:server:mfa",
   "amr": ["pwd", "otp"]
}

Comment le met-on en œuvre avec WSO2 Identity Server?

Il est possible de mettre en œuvre cette fonctionnalité avec WSO2 IS. Pour cela il vous faudra utiliser l’authentification adaptive et en particulier le template “ACR-based”.

Nous allons prendre pour exemple le scénario suivant:

L’application cliente nécessite une authentification pour accéder à son espace utilisateur, mais certaines zones manipulant des données personnelles sont jugées sensibles.

L’application délègue l’authentification à un IAM, WSO2 Identity Server et dialogue avec celui-ci en OpenID Connect 1.0

2 contextes d’authentification sont définis :
- urn:com:monsite:1FA : authentification traditionnelle nom d’utilisateur et mot de passe sous TLS
- urn:com:monsite:2FA : authentification traditionnelle nom d’utilisateur et mot de passe sous TLS en premier facteur et usage d’un OTP mail en second facteur

Configuration de votre instance WSO2 Identity Server

Premièrement il nous faut déclarer un nouvel Identity Provider dans WSO2 IS pour gérer l’OTP. Nous allons utiliser pour cela l’envoi d’un OTP par e-mail selon la documentation suivante :
https://is.docs.wso2.com/en/latest/learn/configuring-email-otp/#configuring-email-otp

notre fichier repository/conf/deployment.toml doit activer le mode d’authentification par Email OTP comme ceci :

[authentication.authenticator.email_otp] 
name ="EmailOTP" 
enable=true 
[authentication.authenticator.email_otp.parameters] EMAILOTPAuthenticationEndpointURL = "https://localhost:9443/emailotpauthenticationendpoint/emailotp.jsp" 
EmailOTPAuthenticationEndpointErrorPage = "https://localhost:9443/emailotpauthenticationendpoint/emailotpError.jsp" 
EmailAddressRequestPage = "https://localhost:9443/emailotpauthenticationendpoint/emailAddress.jsp" 
usecase = "local" 
secondaryUserstore = "primary" 
EMAILOTPMandatory = false 
sendOTPToFederatedEmailAttribute = false 
federatedEmailAttributeKey = "email" 
EmailOTPEnableByUserClaim = true 
CaptureAndUpdateEmailAddress = true 
showEmailAddressInUI = true 
useEventHandlerBasedEmailSender = true

Il doit également contenir la configuration pour joindre notre serveur SMTP :

[output_adapter.email] 
from_address= "wso2iamtest@gmail.com" 
username= "wso2iamtest" 
password= "Wso2@iam70" 
hostname= "smtp.gmail.com" 
port= 587 
enable_start_tls= true 
enable_authentication= true

Déclaration d’un Identity Provider Email OTP

Il vous faudra ensuite déclarer un Identity Provider avec le Federated Authenticator Email OTP d’activé.

Déclaration du Service Provider de test

Vous devez ensuite déclarer de manière classique votre application OpenId Connect :

Configuration de l’authentification adaptive

Une fois la connexion à votre application OpenID Connect déclarée il vous faut configurer une authentification avancée dans la section Local & Outbound Authentication Configuration avec une étape pour chaque type d’authentification souhaitée:

il ne vous reste plus qu’à mettre en œuvre le template ACR de l’authentification adaptive pour orchestrer vos 2 étapes :

Et voilà!

… mais… on a pas oublié quelque chose? Comment sont définies les valeurs de AMR?

WSO2 utilise par défaut les noms des composants d’authentification mis en œuvre comme BasicAuthenticator, SMSOTP, totp, FIDOAuthenticator, EmailOTP, etc.

OK mais c’est pas très intuitif, cohérent et indépendant de la solution! Pas de panique il y a une solution à ça! mais pas encore templatisé dans le fichier toml… (voir https://github.com/wso2/product-is/issues/6854)

Vous devez éditer le template de configuration repository/resources/conf/templates/repository/conf/identity/identity.xml.j2 et ajouter une section définissant le mapping entre les noms des composants et leur nom contextuel :

<AuthenticationContext>
         <MethodRefs>
             <MethodRef uri="pwd" method="BasicAuthenticator"  />
             <MethodRef uri="otp" method="EmailOTP"  />
         </MethodRefs>
</AuthenticationContext>

Cette fois-ci, c’est tout bon!