Sécurité de l'application Web intranet

Question

Utilisation d'Active Directory/Windows L'authentification intégrée est une donnée. Du point de vue du développement, quelle est la meilleure façon de consommer cela?

Est-ce la configuration?

<location path="SecurePage.aspx"> 
    <system.web> 
     <authorization> 
      <allow roles="MyDomain\My Secure Users" /> 
      <deny users="*" /> 
     </authorization> 
    </system.web> 
</location> 

Est-ce par le biais de code?

User.IsInRole(@"MyDomain\My Secure Users"); 

Est-ce une bonne idée de stocker cela dans une base de données? Donc, l'octroi de nouveaux utilisateurs/groupes peut être fait via une application personnalisée? (Je pose cette question parce que c'est le statu quo.) Qu'est-ce qui ne va pas avec cette idée?

Answer 1

Il n'y a aucune raison de ne pas pouvoir utiliser les deux. Faire à travers le web.config est vraiment simple et efficace. Toujours opérer au niveau du rôle bien. Vous utilisez la version de code pour les scénarios où vous avez une utilisation où la configuration n'est pas suffisante, et également lorsque vous souhaitez afficher/masquer des parties spécifiques de l'interface utilisateur (il existe également des versions de contrôle de cette).

Mise à jour 1: Vous avez déjà des supports pour les rôles, donc je suppose que la base de données doit réellement mapper les rôles aux fonctions. Le support intégré d'Asp.net et les points d'extensibilité qu'il supporte sont au niveau du rôle. Si vous avez vraiment besoin d'être complètement dynamique, alors vous devez faire la vérification au niveau du code (le .config fonctionne sur les rôles). C'est une question d'effort supplémentaire, cela dépend donc plus de la taille du système. Pour la plupart des cas, coller avec les rôles est suffisant.

Answer 2

Si cela ne va pas beaucoup changer, utilisez le web.config.

Si cela va beaucoup changer, utilisez la méthode du code mais avec une base de données pour la rendre facilement modifiable.

Plus une réponse générale aux pratiques de codage plutôt que liées à la sécurité.

Answer 3

Personnellement, je préfère une approche déclarative (c'est-à-dire l'approche web.config basée sur l'emplacement). Cela rend plus facile d'apporter des modifications si nécessaire sans nécessiter de redéploiement de code.

En aucun cas, je recommande d'appeler User.IsInRole() avec une chaîne statique comme vous le faites dans votre exemple; utilisez l'approche déclarative web.config si votre auth ne change pas. Le chemin que vous suggérez dans votre dernier paragraphe est parfait, mais je ne le recommande que pour les situations où vos informations d'authentification sont susceptibles de changer fréquemment, par exemple pour les applications CMS ou similaires.

En bref, je ne pense pas qu'il existe une «meilleure pratique» sur le sujet; Cela dépend vraiment de l'application.