Gestion des droits (Identity et Role) avec asp.net core

Voyons ensemble comment paramétrer la gestion des droits avec asp.net core (mvc et razor page).
Nous allons dĂ©couvrir ensemble la crĂ©ation du IdentityContext, la gestion des rĂ´les, …

Paramétrage du context

Création d’un context normal, sans lien avec une gestion des droits.

Puis, définir le context comme gérant les droits

Notons ici le IdentityDbContext.

Il a déjà tous les DbSets dédiés pour la gestion des droits.

Puis, nous configurons le lien avec Identity

Notons ici que nous pouvons créer notre propre utilisateur. Il doit hériter alors de IdentityUser.



Utilisation du Scaffolder

Si aucun paramétrage existe de base, nous pouvons utiliser le scaffolder intégré à dotnet / vs

Choisissez Identité

Nous pouvons récupérer l’ensemble des pages pré-codées pour nous :

Et créer les classes pour le context et pour l’utilisateur

Cela permet aussi de préparer les middlewares pour :

  • L’authentification
  • L’autorisation

Différences entre authentification et autorisation :

Authentication vs. Authorization: What’s the Difference? | OneLogin

Authentication vs. Authorization

Authentication : vérifier que la personne que vous êtes est vraiment celle-ci

Autorisation : gestion des droits par rapport à un profil authentifié

C’est pourquoi nous avons :

Note: il faut rajouter cette ligne juste avant le app.run pour que tout fonctionne avec les fichiers auto-gĂ©nĂ©rĂ©s : 

app.MapRazorPages(); 

PrĂ©paration et lancement de la migration 

dotnet ef migrations add first-with-rights

Bien compiler avant de lancer la commande.

On peut obtenir l’erreur suivante 

https://stackoverflow.com/questions/71011516/c-sharp-entity-framework-core-unable-to-resolve-service

https://bugs.mysql.com/bug.php?id=106592

L’idée ici c’est d’ajouter le paramétrage nécessaire pour le design time (ce qui est utilisé par le moteur de création des migrations)

Un dossier Migrations est apparu : Victoire !

Un snapshot vient d’être créé à côté de la première migration.

On peut alors mettre à jour la base de données :

dotnet ef database update

On peut tomber sur cette erreur :

Ne pas mettre (localhost) dans la partie Server. Bien préciser : 127.0.0.1

Les tables sont créées ! 

Étapes de paramétrage

Ajout d’un rôle

Mise Ă  jour dans le program.cs

Ajout d’un rôle. Notons ici la possibilité de créer notre propre classe de rôle.

Ajout d’une règle par défaut pour toutes les pages

Ici, nous utilisons le builder dédié qui oblige à être authentifié pour toutes les pages.

Pour Ă©viter une boucle infinie au dĂ©marrage et aussi permettre Ă  tout le monde d’avoir un point de chute s’ils ne sont pas connectĂ©s : 

Ça va surpasser les droits de sauvetage.

Seed de données pour le dev

On peut préparer des données à renseigner au démarrage de l’application, en dev par exemple.

RĂ©cupĂ©rer un context Scoped 

Et pouvoir ainsi renseigner :

  • les rĂ´les par dĂ©faut
  • les admins et users de base

Définition des rôles

Définition des users

Ajout de règles par Roles

Attention mettre un Authorize sur le controller supplante toute règle spécifique par action !

On peut spécifier une règle par Policy

Et l’utiliser après dans n’importe quel controller  / action

Customiser la création des users (règles)

IdentityOptions permet de préciser plusieurs parties :

  • Les règles sur le mot de passe
  • Les règles pour le blocage de compte si mauvaise tentative
  • Les règles pour le nommage de compte
  • …

Règle d’authentication + cookie

Nous pouvons aussi définir les règles autour du cookie d’authentication (httponly ou non, …), les règles pour la redirection si non autorisé, …

Ca éveille votre curiosité ?! 🙂

Envie d’en savoir plus

De maîtriser asp.net core ?

Notre adresse

1 rue du guesclin
44000 Nantes

Notre téléphone

+33 2 79 65 52 87

Société

DevToBeCurious SARL
84860163900018 - Nantes B 848 601 639