sécurité de site Web asp.net configurable par le client pour un contrôle précis de l'accès aux pages et aux boutons

Question

J'ai un site Web ASP.NET 2.0 [pas ajax ...] qui sera déployé sous forme compilée sur plusieurs sites clients . Généralement, le site sera uniquement intranet. Certains clients font confiance à tous leurs employés et ne se soucient pas de limiter l'accès au site et/ou aux fonctions de la page, d'autres ne font confiance à personne et veulent que certaines personnes et/ou groupes puissent voir certaines pages, cliquer sur certains boutons, Al. Je pourrais faire une solution locale, peut-être conduire les autorisations d'accès à partir d'une table de base de données, mais avant que je descende cette route je pensais que je demanderais à SO: quelle est une bonne solution pour cette situation? de préférence, celui qui peut être contrôlé complètement dans le fichier web.config et/ou la base de données, car la reconstruction du site web n'est pas possible (pour le client, et je ne veux pas avoir à le faire pour eux encore et encore). L'intégration d'Active Directory serait un bonus, mais pas une exigence (à moins que ce ne soit plus simple).

comme point de départ, je pense que donner chaque page/point de fonction dans le site une identité et associé à un groupe d'autorisation ...

EDIT: section d'autorisation web.config pour permettre/refuser l'accès par rôle et utilisateur est bon, mais ce n'est que la moitié du problème - l'autre moitié contrôle l'accès aux méthodes individuelles (boutons, peu importe) sur chaque page. Par exemple, certains utilisateurs peuvent voir quelles peuvent être les adresses, tandis que d'autres peuvent modifier, créer, supprimer ou désactiver/activer. Tous ces boutons/liens/actions sont sur la page de vue ...

[Idéalement je voudrais faire les boutons invisibles handicapés, mais ce n'est pas important ici]

EDIT: quelques bonnes suggestions à ce jour, mais pas de solution complète encore - se penchant toujours vers une solution axée sur base de données ...

• autorisation de sécurité des attributs de la demande jetteront exceptions lorsque les boutons sont cliqués, ce qui est une chose facile à faire; Je préférerais cacher les boutons que l'utilisateur n'est pas autorisé à utiliser
• Le contrôle LoginView est également intéressant, mais nécessiterait la réplication de la majeure partie du contenu de la page plusieurs fois (une fois pour chaque rôle) et peut ne pas gérer le cas où un l'utilisateur est dans plus d'un rôle - je ne peux pas supposer que les rôles sont hiérarchiques, car ils seront définis par le client

EDIT: la plate-forme est Win2K/XP, SQL Server 2005, ASP.NET 2.0, ne pas utiliser AJAX

Answer 1

Je préfère accorder des droits d'accès aux groupes AD plutôt qu'aux utilisateurs spécifiques. Je trouve que c'est beaucoup plus flexible.

Je ne sais pas grand-chose au sujet de votre application, mais vous pouvez regarder l'étiquette d'autorisation dans le fichier web.config:

<authorization> 
    <!-- 
     <deny users="?" /> 
     <allow  users="[comma separated list of users]" 
        roles="[comma separated list of roles]"/> 
     <deny  users="[comma separated list of users]" 
        roles="[comma separated list of roles]"/> 
    --> 
</authorization> 

Vous pouvez séparer web.config fichiers chaque répertoire dans votre web application, et vous pouvez imbriquer des répertoires. Chaque fichier web.config peut avoir sa propre section d'autorisation. Si vous placez des pages différentes dans chaque répertoire, vous pouvez efficacement gérer la sécurité en autorisant un rôle spécifique dans chaque fichier web.config, et en refusant tout le reste. Ensuite, vous pouvez gérer les membres de chaque rôle dans le répertoire actif. J'ai trouvé ceci pour être une solution affective, car il fait bon usage du cadre de sécurité Active Directory et ASP.NET de Microsoft sans écrire vos propres trucs personnalisés, et si vous utilisez des rôles, il est possible de décharger la gestion de l'appartenance à quelqu'un n'a jamais besoin de toucher le fichier web.config dont ils ont juste besoin pour savoir comment utiliser la console de gestion AD.

Answer 2

Bien que je n'ai jamais utilisé cela auparavant dans la pratique et que je ne puisse pas argumenter ses mérites, je sais que .NET a une sécurité de code basée sur les rôles qui vous permet de verrouiller déclarativement les méthodes par rôle ou utilisateur. Par exemple:

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "MyUser", Role = "User")] 
public static void PrivateInfo() 
{ 
    //Print secret data. 
    Console.WriteLine("\n\nYou have access to the private data!"); 
} 

Rôle de sécurité basé est couvert de façon plus détaillée here. Je ne sais pas si cela vous aidera beaucoup, mais cela nécessitera une recompilation pour le changer; Cependant, le fait d'apposer des étiquettes sur les méthodes est plus rapide que la création d'une logique pour afficher/masquer les boutons ou effectuer une validation de sécurité dans le code.

En outre, vous souhaiterez read up sur l'authentification Windows intégrée pour bénéficier de la possibilité Active Directory.

Answer 3

Il semble que vous pouvez utiliser le contrôle LoginView, qui peut afficher des panneaux de contrôle uniquement pour certains utilisateurs ou rôles. Les rôles sont les plus flexibles: si aucune sécurité n'est requise, placez tous les utilisateurs dans tous les rôles.

utilisation en combinaison avec la sécurité standard web.config (fenêtres intégrées avec Active Directory ou l'authentification des formulaires (le asp 2 schéma du serveur sql ou votre propre).

<asp:LoginView id="LoginView1" runat="server"> 
        <RoleGroups> 
         <asp:RoleGroup Roles="Admin"> 
          <ContentTemplate> 
           <asp:LoginName id="LoginName2" runat="Server"></asp:LoginName>, you 
           are logged in as an administrator. 
          </ContentTemplate> 
         </asp:RoleGroup> 
         <asp:RoleGroup Roles="User"> 
          <ContentTemplate> 
           <asp:Button id="Button1" runat="Server" OnClick="AllUserClick"> 
          </ContentTemplate> 
         </asp:RoleGroup> 
        </RoleGroups> 
       </asp:LoginView> 

Answer 4

je pense que je vais avoir de combiner l'autorisation AD avec «caractéristiques et autorisations de tables dans la base de données afin d'obtenir le contrôle à grains fins que nous avons besoin -

• utiliser le fichier web.config pour permettre aux seuls utilisateurs autorisés (par groupes AD) à visitez le site Web
• créer un tableau "Caractéristiques" répertoriant chaque page et fonctionnalité qui peut être affectée, par ex. page 1 modifier le bouton, page 2 supprimer le bouton, page 3 grille détaillée, etc
• faire une table 'permissions' specfying une fonctionnalité et un groupe AD qui est autorisé à utiliser la fonctionnalité
• modifier les pages du site pour vérifier la fonctionnalité -permissions à la page charge (ou prerender, selon le cas) pour désactiver/masquer caractéristiques interdites comme appropriées

exemples:

• les administrateurs peuvent utiliser toutes les fonctionnalités du site
• les développeurs peuvent utiliser un Caractéristiques ll du site
• Les gestionnaires peuvent voir toutes les pages, mais ne peuvent ajouter et modifier des informations, aucune suppression
• Les superviseurs peuvent voir des résumés pour tous les ministères, mais voir et modifier les détails que pour leur propre service (il y a un an groupe pour chaque département et département-superviseur)
• le personnel peut consulter les détails que pour leur département
• etc.

la solution finale a réduit la notion de « fonction » à un binaire peut utiliser ou cannot- décision d'utilisation et ajout d'un indicateur "permissif/non permissif" à chaque entité. Cela permet aux fonctionnalités que tout le monde peut utiliser pour être définies comme "permissives", puis la table des autorisations doit uniquement enregistrer les groupes auxquels l'autorisation d'utiliser cette fonctionnalité est refusée. Pour une fonctionnalité définie comme non permissive, par défaut personne ne peut utiliser la fonctionnalité et vous devez créer des entrées de table d'autorisation pour les groupes autorisés à utiliser la fonctionnalité.Cela semble donner une solution du meilleur des deux mondes en ce qu'elle réduit le nombre d'enregistrements d'autorisation requis pour chaque fonctionnalité.

Answer 5

Je pense que ce que vous devez faire ici est de mettre en œuvre un ensemble de méthodes de requête d'autorisations dans vos objets métier ou votre contrôleur. Exemples: CanRead(), CanEdit(), CanDelete()

Lorsque la page s'affiche, elle doit interroger l'objet métier et déterminer les fonctionnalités autorisées par l'utilisateur et activer ou désactiver les fonctionnalités en fonction de ces informations. L'objet métier peut, à son tour, utiliser des rôles ou des requêtes de base de données supplémentaires pour déterminer les autorisations de l'utilisateur actif.

Je n'arrive pas à trouver un moyen de définir ces autorisations de façon centralisée. Ils doivent être distribués dans la mise en œuvre des fonctions. Cependant, si vous souhaitez améliorer la conception, vous pouvez utiliser l'injection de dépendance pour insérer des autorisateurs dans vos objets métier et ainsi séparer les implémentations.

Il y a du code qui utilise ce modèle dans le livre de Rocky Lhotka. La nouvelle version n'est pas encore au Google.