Blog de JP Gouigoux

Objectif

Comme annoncé lors du précédent épisode (http://gouigoux.com/blog-fr/?p=3781), le présent article va se concentrer sur la mise en place des API et, pour continuer la phase d’authentification sur le client déjà réalisée, propager l’identification vers le serveur et mettre en place un système d’autorisations de type RBAC et en mode “défense en profondeur”.

Le principe du “Role-Based Access Control” est de donner des autorisations d’accès aux ressources en fonction du ou des rôles portés par un compte utilisateur ou par un groupe auxquels ce compte appartient. Ces rôles sont désignés par un identifiant et définissent des ensembles de droits sur des ressources (par exemple, lire des contrats, ou bien enregistrer des données de personnes, etc.). Dans l’épisode 1 de cette série d’articles (http://gouigoux.com/blog-fr/?p=3775), deux rôles ont été définis dans Keycloak, à savoir administrateur et lecteur. Comme leur nom l’indique, le premier a tous les droits et le second des droits sur les ressources, mais uniquement en consultation.

Par “défense en profondeur”, on entend qu’un seul rideau de gestion des autorisations ne suffit pas et que des strates successives de vérification seront mises en place pour améliorer la sécurité d’accès. Ainsi, les droits seront validés pour accéder à un menu, puis sur le routage correspondant, mais également au niveau du composant Blazor qui s’affiche, ainsi qu’au moment de l’appel sur l’API. Ainsi, si une mesure de sécurité au niveau du client est mise en défaut, une autre pourra implémenter le mécanisme d’autorisation. Et dans tous les cas, le serveur implémentera bien sûr son propre rideau, car les autorisations ne peuvent pas être confiées au client : lorsqu’il les traite, c’est uniquement pour faciliter le parcours d’interface utilisateur en masquant des menus ou composants sur lesquels l’utilisateur ne pourrait de toute façon pas réaliser une action.

Propagation de l’identification

Pour varier les plaisirs par rapport au client (et pour simplifier la lecture de cet épisode assez long), les paramètres du fournisseur d’identité ne seront pas rajoutés dans le fichier appsettings.json du projet TestOIDCBlazorWASM.Server mais en dur. Le code à rajouter dans Program.cs est donc le suivant (il faut le placer avant l’appel à la fonction Build() sur la variable builder) :

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(o =>
{
     o.Authority = “http://localhost:8080/realms/Coucou/”;
     o.Audience = “account”;
});

Ce code permet de faire en sorte que le serveur utilise la même IAM que le client, en se basant pour récupérer l’identité en cours sur le JSON Web Token qui lui sera passé par l’intermédiaire du header HTTP Authorization, préfixé par le texte Bearer suivi d’un espace (comme cela est fait pour l’authentification de base, avec Basic suivi d’un espace). Pour qu’il compile, il est nécessaire de rajouter le package nommé Microsoft.AspNetCore.Authentication.JwtBearer et de positionner un using avec le même contenu en haut du code source.

Pour l’instant, nous ne rajoutons rien de plus à ce niveau du code. Attention toutefois à ne surtout pas se tromper sur l’orthographe de la valeur de l’audience, sous peine d’erreurs 401 incompréhensible, comme le rédacteur a pu s’en rendre compte…

Mise en place d’une API

Pour mettre en œuvre des autorisations, il faut des ressources à protéger : c’est ce que nous allons ensuite rajouter en mettant en place un contrôleur d’API qui exposera des données de personnes.

Pour cela, un contrôleur est ajouté sur le dossier Controllers du projet Server :

Le contrôleur sera de type API, et on démarre avec un contenu vide, et un nom de fichier (étape suivante de l’assistant) qui sera PersonnesController.cs :

L’implémentation dans un premier temps est quasi-vide, le but étant uniquement de tester dans cette étape du blog que les autorisations fonctionnent bien en lien avec l’identification du compte connecté :

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using TestOIDCBlazorWASM.Shared;

namespace TestOIDCBlazorWASM.Server.Controllers
{
     [Route(“api/[controller]”)]
     [ApiController]
     public class PersonnesController : ControllerBase
     {
         [HttpGet]
         public IActionResult LecturePersonnes(
             [FromQuery(Name = “$skip”)] int skip = 0,
             [FromQuery(Name = “$top”)] int top = 10
         )
         {
             return new OkObjectResult(new List<Personne>());
         }

        [HttpPost]
         public IActionResult CreationPersonne([FromBody] Personne personne)
         {
             throw new NotImplementedException(“Fonction de création de personne à venir”);
         }
     }
}

Pour que ce code compile, il faut ajouter une classe Personne, que nous mettrons dans le projet Shared (ne pas confondre avec le dossier du même nom dans le projet Client), et dont le contenu sera comme suit :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace TestOIDCBlazorWASM.Shared
{
     public class Personne
     {
         public string? ObjectId { get; set; }

        public string? Patronyme { get; set; }

        public string? Prenom { get; set; }

        public string? URLFiche { get; set; }
     }
}

Consommation sur le client

Pour vérifier le fonctionnement, une page doit être ajoutée sur le projet Client. Le fichier correspondant sera positionné dans le répertoire Pages :

Le nom du fichier sera Personnes.razor, car il affichera une liste de personnes, et son contenu en première intention sera comme suit :

@page “/personnes”
@using Microsoft.AspNetCore.Authorization
@using TestOIDCBlazorWASM.Shared
@inject IHttpClientFactory HttpFactory

<PageTitle>Personnes</PageTitle>

<AuthorizeView>
     <Authorized>
         @if (personnes == null)
         {
             <p><em>Loading…</em></p>
         }
         else
         {
             <table class=”table”>
                 <thead>
                     <tr>
                         <th>Prénom</th>
                         <th>Nom</th>
                         <th>Fiche</th>
                     </tr>
                 </thead>
                 <tbody>
                     @foreach (var p in personnes)
                     {
                         <tr>
                             <td>@p.Prenom</td>
                             <td>@p.Patronyme</td>
                             <td><a href=”@p.urlFiche” target=”_blank”>Fiche</a></td>
                         </tr>
                     }
                 </tbody>
             </table>
         }
     </Authorized>
     <NotAuthorized>
         <h1>Personnes</h1>
         <div>L’accès à cette page nécessite d’être authentifié</div>
     </NotAuthorized>
</AuthorizeView>

@code {
     private Personne[]? personnes;

    protected override async Task OnInitializedAsync()
     {
         var client = HttpFactory.CreateClient(“WebAPI”);
         personnes = await client.GetFromJsonAsync<Personne[]>(“api/personnes”);
     }
}

Il faudra rajouter une dépendance à la librairie Microsoft.Extensions.Http. pour que la référence à l’interface IHttpClientFactory puisse fonctionner. Ainsi, la fonction CreateClient en fin du code de la classe ci-dessous pourra fournir un client HTTP. La valeur du paramètre WebAPI doit se retrouver sur le code qui va être rajouté dans Program.cs, à savoir :

builder.Services
     .AddHttpClient(“WebAPI”, client => client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
     .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();

Ce code remplace la ligne suivante, qui injecte un HttpClient pour tous les usages, alors que nous souhaitons avoir une instance pour les appels autorisés et une autre pour les appels hors connexion :

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });

Fonctionnement des autorisations sur le client

La balise <AuthorizeView> utilisée plus haut permet de faire en sorte que seuls des accès authentifiés sont réalisés sur la liste des personnes. Ainsi, si on lance l’application et qu’on navigue sur /personnes, l’affichage est le suivant :

Alors qu’une fois authentifié, l’accès est autorisé (même si l’API ne renvoie pour l’instant qu’une liste de personnes vide) :

Dans le premier cas, il y avait en plus une erreur dans l’exécution de l’application côté client :

Ceci est lié à l’implémentation très basique de l’appel à l’API, qui se réalise systématiquement à l’appel de la page, et sans gestion d’erreur pour l’instant. Mais nous allons remédier (partiellement) à ceci avec une approche un peu plus élégante.

Pré-autorisation côté client

En fait, ce que nous faisons sur le client n’est pas réellement de l’autorisation, car tant que le serveur n’est pas protégé (ce qui sera fait un peu plus loin), la donnée peut être accédée par un appel direct à l’API. Tout ce que nous faisons sur le client n’est qu’une sorte de pré-autorisation, bref une amélioration d’ergonomie pour ne pas rendre visibles des moyens d’accéder à la donnée. Il ne faut toutefois pas négliger cet aspect, pour l’utilisabilité de l’application avant tout, mais aussi parce que cela constitue toujours un rideau de défensif supplémentaire (aisément contournable par des sachants, mais tous les utilisateurs ne le sont pas).

Nous allons justement multiplier ces premiers rideaux de défense comme il se doit, en ajoutant au passage un menu pour accéder à cette page que nous avons pour l’instant appelé manuellement.

L’ajout d’un menu se fait en rajoutant le code suivant dans Shared/NavMenu.razor :

<div class=”nav-item px-3″>
     <NavLink class=”nav-link” href=”personnes”>
         <span class=”oi oi-list-rich” aria-hidden=”true”></span> Personnes
     </NavLink>
</div>

Mais pour montrer un premier rideau de blocage (absence du menu si pas d’authentification), nous allons l’entourer des mêmes balises que dans Personnes.razor. Le code est ainsi comme suit (extrait de la classe complète) :

<div class=”@NavMenuCssClass” @onclick=”ToggleNavMenu”>
     <nav class=”flex-column”>
         <div class=”nav-item px-3″>
             <NavLink class=”nav-link” href=”” Match=”NavLinkMatch.All”>
                 <span class=”oi oi-home” aria-hidden=”true”></span> Home
             </NavLink>
         </div>
         <div class=”nav-item px-3″>
             <NavLink class=”nav-link” href=”counter”>
                 <span class=”oi oi-plus” aria-hidden=”true”></span> Counter
             </NavLink>
         </div>
         <div class=”nav-item px-3″>
             <NavLink class=”nav-link” href=”fetchdata”>
                 <span class=”oi oi-list-rich” aria-hidden=”true”></span> Fetch data
             </NavLink>
         </div>
         <AuthorizeView>
             <Authorized>
                 <div class=”nav-item px-3″>
                     <NavLink class=”nav-link” href=”personnes”>
                         <span class=”oi oi-list-rich” aria-hidden=”true”></span> Personnes
                     </NavLink>
                 </div>
             </Authorized>
          </AuthorizeView>
     </nav>
</div>

Pour aller jusqu’au bout des rideaux de défense, la page Personnes.razor va également être protégée du point de vue du routage. Ainsi, même si quelqu’un ne voyant pas le menu continue à saisir l’URL, c’est l’accès à l’ensemble de la page qui sera interdit (et pas seulement le contenu différencié comme réalisé plus haut). Pour cela, en haut de ce fichier, nous ajoutons l’instruction ci-dessus :

@page “/personnes”

@attribute [Authorize]

Ces manipulations ont pour effet que le menu n’apparaît que lorsqu’on est connecté :

Et si un utilisateur tape directement dans l’URL l’adresse correspondante à la page, c’est désormais le mécanisme d’authentification de .NET qui prend la main et réagit de manière plus appropriée, en redirigeant vers l’IAM :

Application des autorisations sur le contrôleur

La partie client est réalisée, mais il nous reste tout de même à gérer l’essentiel, à savoir la sécurité des données elles-mêmes, en protégeant le contrôleur. En effet, pour l’instant, si on appelle directement l’API, le retour est visible (bien qu’il s’agisse pour l’instant d’une liste vide, car nous n’avons rien branché derrière le contrôleur) :

Pour sécuriser le contrôleur, rien de plus simple ; il suffit d’ajouter une balise [Authorize] comme sur le client pour signifier que cet ensemble de méthodes ne peut être accédé qu’avec un compte identifié :

[Authorize]
[Route(“api/[controller]”)]
[ApiController]
public class PersonnesController : ControllerBase

Le résultat est une interdiction, mais pas tellement comme attendu, car nous n’avons pas encore appliqué les mécanismes d’autorisation sur le projet lui-même :

Pour que le mécanisme fonctionne, il faut également indiquer dans le fichier Program.cs les éléments de code suivants pour activer l’authentification et les mécanismes d’autorisation :

app.UseAuthentication();
app.UseAuthorization();

A noter qu’il serait possible de protéger les méthodes une par une au lieu d’appliquer l’attribut à l’ensemble du contrôleur. Nous allons justement utiliser ce mode de fonctionnement un peu plus loin, lorsque nous ajusterons les droits en fonction des rôles de la personne connectée.

Gestion des rôles

Mais dans un premier temps, il est nécessaire de nous assurer que nous disposons bien de ces rôles. Ceci peut être vérifié en récupérant les tokens d’authentification :

En les mettant dans un décodeur comme https://jwt.io, on retrouve bien les claims pour les rôles tels qu’ils avaient été définis lorsque l’IAM a été mise en place dans un épisode principal de cette série (et en particulier pour notre application, dont le ClientID est TestOIDCBlazorWASM) :

Pour indiquer au projet Client où sont les claims pour les rôles, la ligne suivante doit être ajoutée dans l’appel à la fonction AddOidcAuthentication du fichier Program.cs :

options.UserOptions.RoleClaim = “resource_access.TestOIDCBlazorWASM.roles”;

Un peu plus bas, la ligne suivante permet de brancher le mécanisme d’autorisation sur ces claims :

builder.Services.AddApiAuthorization().AddAccountClaimsPrincipalFactory<RolesClaimsPrincipalFactory>();

Pour que cette ligne compile, la classe RolesClaimsPrincipalFactory doit être ajoutée dans le projet (un Principal est une structure .NET qui porte une identité), avec le contenu suivant :

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;
using System.Security.Claims;
using System.Text.Json;

namespace TestOIDCBlazorWASM.Client
{
     public class RolesClaimsPrincipalFactory : AccountClaimsPrincipalFactory<RemoteUserAccount>
     {
         public RolesClaimsPrincipalFactory(IAccessTokenProviderAccessor accessor) : base(accessor)
         {
         }

        public override async ValueTask<ClaimsPrincipal> CreateUserAsync(RemoteUserAccount account, RemoteAuthenticationUserOptions options)
         {
             var user = await base.CreateUserAsync(account, options);
             if (user?.Identity != null && user.Identity.IsAuthenticated)
             {
                 var identity = (ClaimsIdentity)user.Identity;
                 var resourceaccess = identity.FindAll(“resource_access”);
                 string Contenu = resourceaccess.First().Value;

                JsonElement elem = JsonDocument.Parse(Contenu).RootElement;
                 if (elem.ValueKind == JsonValueKind.Array)
                 {
                     foreach (JsonElement e in elem.EnumerateArray())
                         if (e.TryGetProperty(“TestOIDCBlazorWASM”, out var prop))
                         {
                             foreach (JsonElement role in e.GetProperty(“TestOIDCBlazorWASM”).GetProperty(“roles”).EnumerateArray())
                                 identity.AddClaim(new Claim(options.RoleClaim, role.GetString() ?? String.Empty));
                             break;
                         }
                 }
             }
             return user;
         }
     }
}

A noter que cette classe est une version très simplifiée, sans logs ni gestion d’erreur, et avec toutes les valeurs passées en dur pour faciliter la compréhension. Pour avoir une version un peu plus propre, le lecteur est invité à se rendre sur le dépôt Github https://github.com/jp-gouigoux/TestOIDCBlazorWASM.

Exploitation des rôles côté client

Cette classe se chargeant d’incorporer les rôles dans le Principal à partir des claims, nous pouvons maintenant nous servir des rôles sur le client pour, par exemple, autoriser l’accès à la liste des personnes uniquement si le rôle lecteur est présent. Comme nous avons cassé le fonctionnement de la page Fetch data lorsque nous avons modifié le comportement de l’injection par défaut d’un HttpClient (en ne créant qu’une instance pour les besoins connectés), nous en profiterons pour supprimer ce menu qui ne sert plus. De plus, pour montrer la différence entre la gestion connectée et les rôles, nous masquerons le menu pour la page Counter si la personne n’est pas authentifiée ; seul le menu Home sera accessible en cas d’absence de connexion, ce qui est plus conforme au principe de moindre privilège.

Le code correspondant au menu est le suivant :

<div class=”@NavMenuCssClass” @onclick=”ToggleNavMenu”>
     <nav class=”flex-column”>
         <div class=”nav-item px-3″>
             <NavLink class=”nav-link” href=”” Match=”NavLinkMatch.All”>
                 <span class=”oi oi-home” aria-hidden=”true”></span> Home
             </NavLink>
         </div>
        <AuthorizeView>
             <Authorized>
                 <div class=”nav-item px-3″>
                     <NavLink class=”nav-link” href=”counter”>
                         <span class=”oi oi-plus” aria-hidden=”true”></span> Counter
                     </NavLink>
                 </div>
                 @if (context.User.IsInRole(“lecteur”))
                 {
                     <div class=”nav-item px-3″>
                         <NavLink class=”nav-link” href=”personnes”>
                             <span class=”oi oi-list-rich” aria-hidden=”true”></span> Personnes
                         </NavLink>
                     </div>
                 }
             </Authorized>
          </AuthorizeView>
     </nav>
</div>

Logiquement, lors d’un accès non authentifié, le menu est alors réduit à sa plus simple expression :

La connexion avec un compte autorisé permet de voir tous les menus restants :

Et si nous créons dans Keycloak un compte sans aucun rôle, le comportement est le suivant :

Bien sûr, il est également possible de jouer avec les rôles d’un seul utilisateur, en les modifiant dans Keycloak, mais il faudra pour chaque test se déconnecter puis reconnecter :

Toujours sur le client, on peut également modifier l’entête du fichier Personnes.razor pour mettre en œuvre le Role Based Access Control :

@page “/personnes”

@attribute [Authorize(Roles = “lecteur”)]

Exploitation des rôles côté serveur

Le même principe s’applique côté serveur, mais afin de montrer la richesse du mécanisme, nous allons cette fois mettre en place des Policies, qui sont des règles d’autorisations. Ce mécanisme, bien qu’utilisé de manière très simple ci-dessous (lien un pour un avec un rôle) permet de créer des politiques de sécurité très complexes si nécessaire.

Pour cela, nous allons modifier le fichier Program.cs du projet Server comme suit :

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(o =>
{
     IConfigurationSection ConfigOIDC = builder.Configuration.GetSection(“OIDC”);
     o.Authority = ConfigOIDC[“Authority”];
     o.Audience = ConfigOIDC[“Audience”];
     o.TokenValidationParameters.RoleClaimType = “resource_access.TestOIDCBlazorWASM.roles”;
});

builder.Services.AddTransient<IClaimsTransformation, ClaimsTransformer>();

builder.Services.AddAuthorization(o =>
{
     o.AddPolicy(“Administration”, policy => policy.RequireClaim(“user_roles”, “administrateur”));
     o.AddPolicy(“Lecture”, policy => policy.RequireClaim(“user_roles”, “lecteur”));
});

Ce qui nous intéresse particulièrement est la génération de deux Policies, étant entendu qu’elles reprennent ici simplement les codes des rôles. Encore une fois, il s’agit d’un exemple simpliste pour montrer le principe puisque, si nous avions besoin uniquement des rôles, nous pourrions utiliser la même grammaire que plus haut. Mais on voit bien que, comme la façon d’écrire la Policy est avec une lambda, il est possible de combiner toutes les règles imaginables. Les libellés sont toutefois légèrement différents, pour que le lecteur fasse bien la différence par la suite, lorsque les Policies seront utilisées.

Pour que le code compile, il faudra la rajouter la classe suivante, qui se charge de la deuxième fonctionnalité du code présenté, à savoir l’extraction des rôles depuis les claims transmis dans le token :

using Microsoft.AspNetCore.Authentication;
using System.Security.Claims;
using System.Text.Json;

namespace TestOIDCBlazorWASM.Server
{
     public class ClaimsTransformer : IClaimsTransformation
     {
         public Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
         {
             ClaimsIdentity claimsIdentity = (ClaimsIdentity)principal.Identity;
             if (claimsIdentity.IsAuthenticated)
             {
                 foreach (var c in claimsIdentity.Clone().FindAll((claim) => claim.Type == “resource_access”))
                 {
                     JsonDocument doc = JsonDocument.Parse(c.Value);
                     foreach (JsonElement elem in doc.RootElement.GetProperty(“TestOIDCBlazorWASM”).GetProperty(“roles”).EnumerateArray())
                         claimsIdentity.AddClaim(new Claim(“user_roles”, elem.GetString() ?? String.Empty));
                 }
             }
             return Task.FromResult(principal);
         }
     }
}

Enfin, l’utilisation des Policies est globalement la même que pour les rôles, seule la grammaire changeant. Dans l’application ci-dessous, le contrôleur est déclaré accessible sur le GET si la politique Lecture est satisfaite, et sur le POST si la politique Administration est satisfaite :

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using TestOIDCBlazorWASM.Shared;

namespace TestOIDCBlazorWASM.Server.Controllers
{
     [Authorize]
     [Route(“api/[controller]”)]
     [ApiController]
     public class PersonnesController : ControllerBase
     {
         [Authorize(Policy = “Lecture”)]
         [HttpGet]
         public IActionResult LecturePersonnes(
             [FromQuery(Name = “$skip”)] int skip = 0,
             [FromQuery(Name = “$top”)] int top = 10
         )
         {
             return new OkObjectResult(new List<Personne>());
         }

        [Authorize(Policy = “Administration”)]
         [HttpPost]
         public IActionResult CreationPersonne([FromBody] Personne personne)
         {
             throw new NotImplementedException(“Fonction de création de personne à venir”);
         }
     }
}

Lors du lancement, l’erreur suivante apparaît :

Comme nous ne souhaitons pas rentrer dans la complexité d’une exposition HTTPS de Keycloak (pour l’instant, en tout cas), nous suivons le contournement proposé et rajoutons le code suivant dans le code du serveur :

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(o =>
{
     IConfigurationSection ConfigOIDC = builder.Configuration.GetSection(“OIDC”);
     o.Authority = ConfigOIDC[“Authority”];
     o.Audience = ConfigOIDC[“Audience”];
     o.TokenValidationParameters.RoleClaimType = “resource_access.TestOIDCBlazorWASM.roles”;
     o.RequireHttpsMetadata = false;
});

Le lancement est ensuite conforme à celui attendu :

Conclusion

Au prochain épisode, branchement sur la base de données et ajout d’une page pour créer des personnes, de façon à boucler la partie de base de l’application avec son IAM associée.

Vue la complexité pour écrire le présent article avec Open LiveWriter qui date de plus de 10 ans et le résultat moche pour le code source, je pense qu’il est temps de basculer vers un autre système de bloc, avec peut-être du Markdown pour générer un blog statique… A suivre sur le prochain article de cette série, que j’espère écrire plus vite que celui-ci, longtemps remis à plus tard.

Objectif

Le but de cet article est de montrer comment l’IAM préparée sur le précédent article (http://gouigoux.com/blog-fr/?p=3775) va être utilisée par l’application cliente pour son authentification / identification. Dans cet article, nous n’utiliserons pas encore l’identification pour réaliser des autorisations dans le client, et nous ne propagerons pas l’authentification sur le serveur. Ces deux sujets seront traités dans d’autres articles à venir. Pour l’instant, le but est juste de montrer comment authentifier proprement un client Blazor sur une source OpenID Connect.

Vous êtes certainement déjà tombés sur des articles comme https://betterprogramming.pub/stop-using-json-web-tokens-for-authentication-use-stateful-sessions-instead-c0a803931a5d, mettant en garde sur la mauvaise utilisation des tokens JWT, et il faut effectivement faire attention à ne pas créer des failles de sécurité. C’est pour cette raison que, dans l’application exemple, nous collerons au maximum à l’utilisation la plus standard possible des librairies .NET. C’est ce qui nous permettra en particulier d’éviter le maximum de pièges de sécurité, car les implémentations fournies sont sécurisées par défaut. Par exemple, le type de flux utilisé sera le mode “code grant” d’OpenID Connect, qui est plus sécurisé que le mode “implicit grant”, désormais abandonné par la vesion OAuth 2.1. Et pour ce qui est des tokens, l’implémentation .NET par défaut gère correctement les id token, access token et refresh token, ce qui donne également une bonne assurance d’évolutivité, par exemple vers la possibilité de révocation d’une session authentifiée.

Création du squelette d’application standard

Toujours pour des raisons de standardisation maximum, nous partirons du modèle Application WebAssembly Blazor de Visual Studio (version 2022 utilisée pour les articles) :

Si vous souhaitez suivre directement les exercices, vous pouvez nommer l’application TestOIDCBlazorWASM, de façon à pouvoir copier directement les ensembles de code faisant référence aux namespaces, sans avoir à les modifier :

Afin de montrer précisément tous les ajouts nécessaires à la bonne gestion de l’authentification et d’expliquer point par point toutes les classes et fonctionnalités pour ce faire, nous partirons, même si cela peut paraître plus de travail, d’une application sans gestion de l’authentification. Et comme le but est d’avoir une application la plus réaliste possible, nous utiliserons le mode HTTPS :

Ajout des composants Blazor à utiliser pour l’authentification

La première étape est d’ajouter le package nécessaire à la gestion de l’authentification dans une application Blazor WASM, à savoir Microsoft.AspNetCore.Components.WebAssembly.Authentication. Pour cela, on va dans la gestion des packages du projet Client :

Et on installe cette librairie qui, au moment de l’écriture de cet article, était en 6.0.8 :

Ensuite, nous allons créer trois composants Razor, dont le code est récupéré sur les templates avec authentification proposés par Microsoft, mais que nous reprendrons ici manuellement :

Le premier sera placé dans Pages, s’appellera Authentication.razor et contiendra le code suivant, nécessaire pour la gestion des routes d’authentification :

@page “/authentication/{action}”
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
<RemoteAuthenticatorView Action=”@Action” />

@code{
     [Parameter] public string? Action { get; set; }
}

Attention à ne pas modifier la route exposée, en tout cas sans ajuster ce qui avait été fait dans le précédent article sur le paramétrage de l’IAM Keycloak, car nous avions déclaré les sous-routes login-callback et logout-callback dans /authentication comme les URLs valides pour l’IAM, et il faut que la correspondance soit gardée sinon l’IAM refusera ces adresses en redirection.

Le second composant sera placé dans Shared et nommé LoginDisplay.razor, avec ce contenu :

@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication

@inject NavigationManager Navigation
@inject SignOutSessionStateManager SignOutManager

<AuthorizeView>
     <Authorized>
         <a href=”authentication/profile”>Hello, @context.User.Identity?.Name !</a>
         <button class=”nav-link btn btn-link” @onclick=”BeginSignOut”>Log out</button>
     </Authorized>
     <NotAuthorized>
         <a href=”authentication/register”>Register</a>
         <a href=”authentication/login”>Log in</a>
     </NotAuthorized>
</AuthorizeView>

@code{
     private async Task BeginSignOut(MouseEventArgs args)
     {
         await SignOutManager.SetSignOutState();
         Navigation.NavigateTo(“authentication/logout”);
     }
}

Ce composant est celui qui gère l’affichage des commandes d’authentification. Tant que l’utilisateur n’est pas identifié, il affiche le lien pour s’enregistrer comme utilisateur (attention, ça ne veut pas dire que l’IAM supporte cette fonctionnalité, et si ce n’est pas le cas, on aura une information en ce sens) et le lien pour se connecter. Dans le cas inverse, l’affichage montrera le contenu du nom fourni par l’instance d’identité générée par .NET à partir des claims d’identification reçus par le ticket JWT, ainsi que le lien pour se déconnecter (d’où l’importance, dans l’article précédent, de bien déclarer aussi l’URL en logout-callback comme valide).

Le troisième composant est également dans Shared, et s’appelle RedirectToLogin.razor. Il contient le code ci-dessous :

@inject NavigationManager Navigation
 
@code {
     protected override void OnInitialized()
     {
         Navigation.NavigateTo($”authentication/login?returnUrl={Uri.EscapeDataString(Navigation.Uri)}”);
     }
}

Comme le nom l’indique, ce composant se charge uniquement de la redirection vers la page de login, en passant en paramètre l’URL sur laquelle rediriger l’utilisateur si la connexion a bien été réalisée (en général, la page d’où l’utilisateur vient, et qui l’a renvoyé sur la page de login comme elle n’a pas détectée d’authentification valide).

Paramétrage de l’authentification

Les composants graphiques étant prêts, nous allons passer à la mise en place de la mécanique d’authentification qui va les mettre en œuvre. Dans un premier temps, il faut rajouter un “Fichier de paramètres d’application” dans le projet Client. Pour les applications Blazor, comme ce fichier doit être lu lors de l’exécution, et donc depuis le navigateur, il doit être ajouté dans wwwroot.

La section ci-dessous est ensuite rajoutée dans le fichier :

“OIDC”: {
  “Authority”: “http://localhost:8080/realms/Coucou/“,
  “ClientId”: “TestOIDCBlazorWASM”,
  “ResponseType”: “code”
}

Attention à ne pas se tromper sur le protocole ni le port d’exposition de Keycloak, et si le conteneur a été arrêté depuis que vous l’avez déployé lors de l’article précédent, il faudra penser à faire un docker start iam. De même, si vous avez nommé le realm autrement que Coucou et le client d’authentification autrement que TestOIDCBlazorWASM, il faut bien sûr ajuster. Noter que le fait que ce dernier soit exactement le nom de l’application est une pure convention pour s’y retrouver, mais rien ne le force. Il est simplement assez logique de les aligner, car le client au sens OIDC est une application appelée à consommer les services d’authentification, et ce sera dans notre cas l’application que nous sommes en train d’initialiser.

Dans le fichier index.html, la ligne ci-dessous est à rajouter juste avant l’inclusion du script blazor.webassembly.js, en toute fin du body (c’est une bonne pratique de toujours inclure les scripts en fin de page) :

<script src=”_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/AuthenticationService.js”></script>

Cette ligne de code permet d’ajouter au client toutes les fonctionnalités Javascript nécessaires pour que l’authentification se déroule correctement (en Blazor WebAssembly, tout n’est pas fait en .NET, et il reste encore des fonctionnalités réalisées en Javascript).

Dans le fichier _Imports.razor, il faut rajouter le using ci-dessous pour que tout compile bien :

@using Microsoft.AspNetCore.Components.Authorization

Le fichier App.razor va nécessiter un peu plus de travail. Déjà, l’ensemble du code existant doit être entouré dans des balises <CascadingAuthenticationState>, ce qui permettra de pousser automatiquement les données d’authentification dans tous les composants à l’intérieur de l’application. Ensuite, la ligne <RouteView…> sera remplacée par le code suivant, qui nous permettra de gérer la redirection automatique (ou bien l’affichage d’un message de blocage) lorsqu’une ressource n’est désormais pas accessible :

<AuthorizeRouteView RouteData=”@routeData” DefaultLayout=”@typeof(MainLayout)”>
     <NotAuthorized>
         @if (context.User.Identity?.IsAuthenticated != true)
         {
             <RedirectToLogin />
         }
         else
         {
             <p role=”alert”>You are not authorized to access this resource.</p>
         }
     </NotAuthorized>
</AuthorizeRouteView>

C’est ce code qui appellera le RedirectToLogin créé plus haut. Le code d’App.razor doit être comme suit :

Il est également nécessaire pour pouvoir se connecter d’incorporer l’appel au composant LoginDisplay créé plus haut dans la barre de menu. On intervient donc dans MainLayout.razor pour ajouter la ligne sélectionnée dans la capture ci-dessous :

Le tout dernier ajout de code dans le client se trouve dans Program.cs et il s’agit du code qui récupère les settings du fichier de paramétrage pour déclencher la prise en compte de l’authentification OIDC par les composants .NET :

builder.Services.AddOidcAuthentication(options => {
     builder.Configuration.Bind(“OIDC”, options.ProviderOptions);
});

Le code doit être placé avant l’instruction .Build() existante dans le code généré par le template Microsoft. Si vous avez modifié le nom de la section dans le fichier de settings créé plus haut, il faut bien sûr ajuster ci-dessus. Le montage réalisé revient exactement au même que si on avait indiqué les valeurs directement dans le code comme suit (mais il est bien sûr plus propre de passer par des paramètres) :

builder.Services.AddOidcAuthentication(options => {
     options.ProviderOptions.Authority = “http://localhost:8080/realms/Coucou/”;
     options.ProviderOptions.ClientId = “TestOIDCBlazorWASM”;
     options.ProviderOptions.ResponseType = “code”;
});

Attention, à titre de remarque, à ne jamais rien mettre de secret dans ce fichier, car il est envoyé dans le navigateur.

Test de la configuration et ajustement

Un premier lancement de l’application et un clic sur le bouton Log in montre qu’il y a une erreur :

L’IAM est bien appelée puisque l’écran qu’on voit est fourni par Keycloak. Mais le message nous précise que l’URI de redirection n’est pas correcte. Le problème vient du fait que, lors de l’article précédent, quand nous avons configuré le client d’authentification, nous sommes partis du principe que l’application serait déployée sur http://localhost:88, alors qu’elle est rendue accessible par Visual Studio en débogage sur un autre port (et en HTTPS, en plus) :

Il est donc nécessaire de retourner dans l’IAM et de changer la configuration comme suit (si vous ne voyez pas comment faire, reportez vous à la page http://gouigoux.com/blog-fr/?p=3775) :

Une fois cette modification réalisée (inutile de relancer l’IAM, la modification est prise en compte immédiatement), on peut bien s’identifier dans le navigateur en cliquant à nouveau sur le bouton Log in de l’application :

Connectez-vous bien sûr avec l’utilisateur que vous avez créé dans l’IAM (nommé jpg dans le précédent article), mais pas l’administrateur déclaré au début pour Keycloak : c’est plus propre pour la sécurité. De plus, pour l’instant, le client n’a pas besoin de rôles ou de droits particuliers pour fonctionner, car nous n’avons branché que l’authentification, mais aucun mécanisme d’autorisation bloquant les appels à telle ou telle fonctionnalité en fonction de l’identité du compte, ou même du fait qu’il n’y ait pas de connexion effective (mode anonyme). En fait, le seul effet de la connexion est pour l’instant que la barre en haut à droite affiche le nom complet de la personne :

Si vous ne voyez pas de nom s’afficher, mais que le message dit tout de même “Hello”, c’est certainement que vous n’aviez pas fourni ces informations lors de la création du compte :

Un dernier test pour vérifier que la déconnexion fonctionne bien et nous sommes arrivés au bout de cet épisode :

Au menu des prochains épisodes, activation de l’autorisation sur le client, ce qui nous amènera à proposer de nouveaux composants métier, à déclarer des API sur le serveur, et ensuite à authentifier et autoriser ces accès serveurs également.

Objectif

La toute première dépendance fonctionnelle de l’application test est l’Identity and Authorization Management : il faut gérer les utilisateurs, leur capacité à prouver leur identité et les attributs d’identification qui découlent de l’authentification, et qui vont servir ensuite pour la gestion des autorisations.

Il s’agit de la toute première découpe claire des responsabilités qu’il est essentiel d’avoir dans une application :

• Identification : ce qui décrit le compte, et par delà le compte la personne qui le possède quand il s’agit de comptes individuels.
• Authentification : preuve que la personne qui manipule le compte est bien celle qui est prévue pour cela. Un mot de passe ou toute autre preuve fait en sorte que l’identification soit validée électroniquement. Attention, on a parfois tendance à en déduire que c’est une preuve d’identité, mais pour cela, il faudrait aussi que le compte soit délivré par une autorité de confiance qui a vérifié que les attributs du compte étaient bien ceux d’une personne physique à laquelle le compte a été confiée. Et encore, cela ne suffit pas dans le sens où une personne peut très bien confier son compte à une autre. Mais dans ce cas, la charge de la preuve d’usurpation est à l’utilisateur (c’est la raison pour laquelle les conditions générales incluent souvent que vous ne devez pas confier votre compte à une autre personne : pour se couvrir en cas de dispute sur l’identité).
• Autorisation : les droits que le compte obtient de par ses attributs d’identité, ou associés à son identité. Par exemple, des groupes d’appartenance, des caractéristiques particulières, etc.

L’IAM Keycloak est un produit open source qui va nous permettre de gérer l’authentification et l’identification des comptes pour notre application. La gestion des autorisations sera réalisée dans l’application, encore que comme elle est basée sur des attributs d’identité, on pourrait dire que l’IAM a une responsabilité partielle (nous y reviendrons, mais sur les 5 responsabilités des autorisations telles que définies dans XACML, l’application sera le PDP, le PRP, le PEP, tandis que l’IAM sera le PIP ; il n’y aura pas de PAP dans un premier temps).

L’authentification sera assurée par le protocole OpenID Connect. L’avantage d’utiliser un tel protocole standard est qu’il nous permettra d’élargir aisément vers des fournisseurs d’authentification différents comme Microsoft LiveID, Google ID, France Connect, etc.

L’identification sera assurée par un simple annuaire interne géré par Keycloak. Dans le futur, peut-être qu’un annuaire LDAP sera utilisé, mais c’est tout l’avantage de passer par le protocole normalisé fourni par Keycloak : l’application se branchera sur OIDC et consommera des tokens JWT, et c’est Keycloak qui fera l’indirection avec les implémentations sur des mots de passe et des caractéristiques stockées localement. Si l’implémentation change, ce sera absolument transparent pour l’application. Afin de tester ceci, nous pourrons par exemple remplacer Keycloak par un LemonLDAP-NG, et vérifier que, le paramétrage mis à jour, l’application fonctionne sans ajustement de code quelconque.

Démarrage de Keycloak

Grâce à Docker, rien de plus simple que de démarrer un server Keycloak :

docker run -p 8080:8080 -d -e KEYCLOAK_ADMIN=armoire -e KEYCLOAK_ADMIN_PASSWORD=vBWtB2PloopC042cszXZ –name iam quay.io/keycloak/keycloak:18.0.2 start-dev

Le nom d’utilisateur n’est pas admin ni administrator ni root ou n’importe quelle autre valeur qui puisse faciliter la vie à un éventuel attaquant. Le mot de passe est robuste (et unique pour ce service + stocké dans un outil comme Keepass). Le port 8080 est réexposé sur la machine locale avec le même numéro. Le conteneur est nommé pour faciliter les manipulations dessus. L’image est dans sa version la plus récente au moment de l’écriture de ce blog. C’est une bonne pratique d’utiliser des images fixes : bien sûr, il faut faire l’effort de réaliser les mises à jour régulières, mais au moins, on ne risque pas d’être surpris en production par une modification non compatible. Le choix dépend toutefois aussi de l’importance de la mise à jour et de la confiance que vous avez dans la capacité du fournisseur à respecter la compatibilité ascendante. Enfin, les arguments de ligne de commande correspondent pour l’instant à un démarrage en mode développement. Dans un article plus loin, nous passerons Keycloak dans un mode plus proche de la production (SSL, gestion de la persistance dans une base de données, etc.).

Pas d’inquiétude si le port ne répond pas tout de suite :

Keycloak est un peu lent à se mettre en route, comme vous pourrez le constater en suivant les logs en mode dynamique :

Une fois démarré pour de bon, la page d’accueil permet d’accéder à la console :

Et vous vous connecterez alors avec le compte et le mot de passe utilisé plus haut :

Nous pouvons passer au…

Paramétrage de Keycloak

Tout d’abord, nous allons paramétrer un tenant dans Keycloak, ce qui s’appelle un royaume (realm en anglais) dans le jargon de l’IAM :

Ce royaume pourrait servir pour authentifier plusieurs utilisateurs pour plusieurs applications : en tant que tenant, il faut vraiment se positionner comme si vous lanciez plusieurs fois l’application Keycloak, sauf que celle-ci vous permet en fait de n’avoir qu’un seul serveur qui tourne, mais avec des contextes complètement étanche que sont les tenants. Pour notre exemple, nous pourrions imaginer le nom d’une société fictice qui s’appellerait Coucou Incorporated. Le royaume sera donc nommé comme ceci :

A l’intérieur de ce royaume, nous allons créer un client. Cette fois, il s’agit de l’entité qui va supporter un mode d’authentification particulier dédié à une application. Comme notre but est d’apporter l’authentification et l’identification à l’application TestOIDCBlazorWASM, il est logique que le client s’appelle pareil :

A noter que le protocole SAML est également proposé, en plus d’OpenID Connect, mais il s’agit d’un protocole plus ancien, et proche de l’obsolescence même si, les choses changeant lentement dans le domaine de l’IAM, il est encore largement utilisé.

Dans le client, nous allons commencer par l’onglet Settings, dans lequel il faudra déclarer les URLs valides pour la redirection. OIDC fonctionne en effet en prenant la main sur le navigateur, en demandant les crédentiels, et ensuite en redirigeant vers la page web initiale tout en lui passant un code qui lui permettra d’appeler en retour le service d’IAM et d’obtenir un token JWT portant l’identification de la personne (en tout cas, dans le flow standard). Par sécurité, les URLs autorisées pour cette redirection doivent donc être spécifiées. Nous anticipons un peu, mais l’application sera déployée dans un premier temps en local, sur le port 88. Et comme nous utiliserons le mécanisme d’authentification intégré de .NET, les URLs à paramétrer sont comme ceci :

Ensuite, pour ne pas avoir de problème de CORS, il faut également déclarer que l’application web est une origine autorisée pour l’appel à l’IAM (sinon la requête avec le code fourni lors de la redirection ne sera pas autorisé). Ceci est fait un peu plus bas dans le même onglet :

Attention à ne surtout pas mettre un slash à la fin, sinon le mécanisme plante ! Oui, c’est très sensible…

Dans l’onglet Roles, déclarez ensuite deux rôles qu’on appellera administrateur et lecteur. Le but est en effet de faire en sorte que l’application soit propre du point de vue RBAC (Role Based Access Control), c’est à dire que les autorisations reposent sur la définitions de rôles associés aux groupes ou aux utilisateurs. La question de la persistance de ces définitions de rôles et de leur association aux attributs d’identité se pose : une séparation stricte des responsabilités voudrait qu’elles se trouvent dans l’application, car seul le métier fonctionnel peut au final définir clairement des autorisations sur les entités qu’il manipule. Mais la tentation de la centralisation de la gestion des rôles est en général forte dans les entreprises, et nous sacrifierons ici à cette approche. Nous reviendrons toutefois sur ce point lors de l’article sur la gestion complète des autorisations, avec XACML ou avec OPA. En attendant, les rôles sont déclarés dans Keycloak, mais sur le client défini (attention à ne pas définir des rôles globaux au niveau du royaume, en utilisant le menu sur la gauche ; c’est bien l’onglet Roles du client juste créé qui doit être utilisé) :

Pour que les rôles soient envoyés lors de l’authentification / identification, il faut créer un mapper qui va les associer au ticket (bouton Add builtin dans l’onglet Mappers). Pour cela, on générera un mapper de type client roles puis on accédera à ce mapper pour modifier le paramétrage et faire en sorte que les rôles soient disponibles aussi dans le token d’identification :

Cette manipulation est nécessaire parce que les rôles seront sinon uniquement dans l’access token, qui est le second JWT utilisé, et envoyé au serveur pour qu’il décide des autorisations. Dans notre cas, l’application est une SPA en Blazor et pour pouvoir n’afficher des menus que si les droits sont présents (ce qui ne veut bien sûr pas dire qu’on peut se permettre de ne pas revérifier les autorisations côté serveur), il faut bien que nous ayons cette info dès la phase d’authentification passée et le premier JWT (celui d’identification) récupéré.

Création d’un utilisateur

Le client (au sens OIDC, à savoir la définition dans l’IAM de l’application autorisée à utiliser le service) étant prêt, il reste à créer un utilisateur. A terme, nous ferons quelque chose de plus sophistiqué en branchant Keycloak sur un annuaire LDAP ou – mieux – sur une application qui simulerait un legacy, ce qui nous permettra de montrer l’extensibilité de Keycloak à l’aide d’un plugin intégré dans un JAR. Mais là encore, j’anticipe…

Pour créer un utilisateur, pas besoin d’explications particulières, ça se passe dans le menu Users. Dans un premier temps, on peut se contenter d’un utilisateur auquel on donnera les deux rôles clients administrateur et lecteur :

Quand vous donnez les crédentiels, inutile de laisser le mode de passe en temporaire : vu que vous utiliserez vous-même le compte, pas besoin qu’on vous demande à la première connexion de changer le mot de passe…

Test

Si vous retournez sur les informations générales du client, vous verrez que les endpoints sont en fait des liens :

En ouvrant le premier, qui est celui qui nous concerne, vous obtenez la définition formelle du endpoint OIDC :

En réduisant l’URL à juste le début, vous accédez à une page plus réduite qui expose la clé publique utilisée par le client, ainsi que l’adresse pour le token et l’adresse pour la gestion de compte :

C’est cette dernière qui nous intéresse pour tester que l’utilisateur fonctionne bien. En allant dessus, vous arrivez sur l’interface de gestion de son compte pour l’utilisateur. Et il peut bien sûr se connecter avec le bouton en haut à droite :

Si ça marche, c’est que l’utilisateur – au moins – est bien créé :

Ca ne veut pas dire que tout est bien paramétré, mais pour l’utilisation de cette IAM dans une application, nous verrons au prochain article !