ASP.NET: Architecture d'autorisation/d'authentification

Question

Je cherche à créer une authentification dans mon application ASP.NET avec les exigences suivantes.

• Un utilisateur a exactement un rôle (à savoir Admin, SalesManager, ventes, ....)
• Un rôle a un ensemble d'autorisations d'accès CRUD un sous-ensemble d'objets existants. C'est à dire. "Sales a CREAD, READ, WRITE autorisation sur le type d'objet" Produits "mais pas DELETE"
• D'une certaine manière, j'aime les autorisations d'être dans une hiérarchie avec l'héritage afin que je n'ai pas besoin de spécifier tous les objets disponibles .
• Le système doit rapidement être en mesure de répondre à la question "Est-ce que l'utilisateur X ont la permission de faire Y pour objet Z"
• Toutes base de données gérée (MSSQL), mis en œuvre en C#/ASP.NET

I aimerait avoir un retour sur ces exigences? Des idées comment implémenter cela en utilisant ASP.NET framework (autant que possible)? (Toutefois, je suis également intéressé de savoir comment cela peut être réalisé sans les adhésions)

Answer 1

Je pense que ce que vous devez faire ici est d'implémenter un ensemble de méthodes de requêtes 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.

Answer 2

L'API d'adhésion fournie depuis ASP.NET 2.0 devrait bien répondre à vos besoins. La seule chose que je crains ne supporte pas directement est les rôles hiérarchiques. Cependant, vous pouvez facilement utiliser la sécurité basée sur le rôle normal avec une autre table de rôles hiérarchiques manuellement écrite pour réaliser les choses requises.

Answer 3

Vous pouvez lire sur la façon de mettre en place des membres ASP.NET ici: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx

Il vous permet de dossiers de groupe/pages etc dans des groupes/utilisateurs. Je pense que vous trouverez cela suffisant!

L'interface est facilement gérée en étendant les bases de données et les procédures générées.

Answer 4

Je pense que l'une des meilleures implémentations que je pense répondra à vos besoins est documentée here. Le seul problème est que cela se connecte à NHibernate, mais vous pouvez l'utiliser comme un modèle pour créer votre propre implémentation d'autorisations et simplement vous connecter à votre propre modèle d'événement plutôt qu'à celui de NHibernates Interceptors.

Je travaille moi-même sur un tel système et j'en ferai un blog dès que j'en serai content.

Answer 5

J'ai créer un projet sur CodePlex qui donne envie que vous voulez: http://www.michaelalbaladejo.com/Projects/ASP-Net-Permission-Management-Part-1

Answer 6

Je construirais la relation utilisateur/rôle afin que les utilisateurs peuvent avoir plus de 1 rôle. Je vois une relation 1-1 et je suis nerveux parce que je sais que même si nous n'en voyons pas la nécessité maintenant, quelqu'un voudra qu'un jour quelqu'un devienne à la fois un utilisateur des ventes et un utilisateur du service à la clientèle.

Dans notre système client, nous utilisons des rôles pour superposer des éléments tels que "delinquentCustomer". De cette façon, les autorisations d'origine sont toujours valables - dès qu'ils paient leur facture. Il vaut la peine d'envisager cette approche.