Une petite méthode m’accroche ces jours-ci : IsInRole, avec WindowsIdentity et WindowsPrincipal. Cette simple vérification fait apparaître une architecture plus saine que If utilisateur = "Jean" Or utilisateur = "Marie".

Une session Windows fournit d’abord une identité. Le contrôleur de domaine vérifie le compte et Windows crée un jeton d’accès contenant son SID, les SID de ses groupes et certains privilèges. WindowsIdentity.GetCurrent() expose l’identité sous laquelle le code s’exécute; WindowsPrincipal interprète son appartenance aux rôles.

Dim principal As New WindowsPrincipal(WindowsIdentity.GetCurrent())

If principal.IsInRole("DOMAINE\Comptabilite") Then
    AfficherModuleFinancier()
Else
    RefuserAcces("Rôle requis: Comptabilite")
End If

Le code parle de comptabilité, pas de Jean, Marie ou Chantal. L’annuaire suit les personnes; l’application applique une règle stable. Mais il faut encore définir ce que le rôle peut faire. Un seul groupe Comptabilite peut être trop large si certaines personnes saisissent les factures, d’autres les approuvent et quelques-unes administrent les périodes.

Je construirais une petite matrice avant le code :

Opération	SaisieFactures	ApprobationFactures	AdminComptable
créer un brouillon	oui	oui	oui
approuver son propre brouillon	non	non	non
approuver le brouillon d’un autre	non	oui	oui
rouvrir une période	non	non	oui

Les groupes Active Directory portent ces rôles. Une méthode d’autorisation centrale traduit ensuite l’opération en groupes acceptés. Je ne disperserais pas cinquante appels IsInRole dans les clics de boutons : une règle oubliée sur un nouvel écran devient une faille. L’interface masque ce qui ne sert pas, puis le service ou la couche métier vérifie encore juste avant la modification.

Le principe du moindre privilège s’applique aussi au compte technique. Si une application ASP.NET s’exécute sous un compte de service, SQL Server voit peut-être ce compte plutôt que la personne. L’application doit alors conserver l’identité de l’utilisateur pour l’audit et faire elle-même l’autorisation. L’impersonation peut transmettre l’identité Windows au serveur Web, mais la délégation vers un deuxième serveur — le fameux double hop — demande une configuration Kerberos précise. Sinon, le premier appel marche et l’accès à SQL échoue sous une identité inattendue.

Les groupes imbriqués simplifient l’administration : un groupe d’équipe peut devenir membre d’un groupe applicatif. Trop de niveaux rendent toutefois la réponse « pourquoi Chantal a accès? » difficile à reconstruire. Le jeton possède aussi une taille finie; des centaines de groupes deviennent un problème technique autant qu’organisationnel.

Une modification de groupe n’apparaît pas nécessairement dans une session déjà ouverte. Le jeton garde les SID obtenus à la connexion. Une révocation urgente doit donc désactiver le compte ou couper les sessions concernées, pas seulement retirer un groupe en espérant que toutes les applications le voient. Si le contrôleur de domaine est inaccessible, je traite l’impossibilité de vérifier comme un échec pour une action sensible.

Le journal d’audit devrait noter qui, quelle opération, quelle ressource, quand et résultat, avec un identifiant de corrélation. Il ne devrait jamais enregistrer le mot de passe ni une copie complète du jeton. Ces traces doivent être protégées contre la modification et conservées selon une durée décidée.

Ma pratique sera donc un test par opération, pas seulement par écran : un compte autorisé, un compte refusé, un compte retiré du groupe et une session encore ancienne. Une permission codée avec le nom d’un employé reste suspecte; un groupe sans propriétaire ni révision périodique le devient aussi.