En fonction de la granularité du contrôle dont vous avez besoin pour votre application, vous pouvez envisager le modèle utilisé dans Windows Identity Foundation (WIF), qui fait désormais partie de .NET Framework 4.5. Il s'agit d'un modèle architecture basée sur les réclamations et le terme utilisé pour ce que vous appelez Entité es Ressources . Ce qui diffère de votre modèle, c'est qu'ils ont également le concept de Fonctionnement . A Ressources peut avoir plusieurs Opérations et d'un Fonctionnement serait quelque chose comme lire, écrire, exécuter. C'est là qu'intervient la granularité plus fine du contrôle.
Dans ce cas, un Fonctionnement pour un Ressources peut avoir plusieurs Rôles et un Rôle peut avoir plusieurs Opérations ce qui nécessite une autre table pour mettre en correspondance cette relation de plusieurs à plusieurs. Utilisation de int comme clé primaire dans Rôles y Opérations en tant qu'identifiants d'objets est une bonne chose pour la performance. Utilisateur peut avoir plusieurs Rôles y Rôles aura de nombreux Utilisateurs Vous aurez donc à nouveau besoin d'une autre table pour gérer cette relation de plusieurs à plusieurs.
La réponse à la question 1 est donc que vous ne stockez pas le Utilisateur dans une liste de Entité table. Vous disposez d'un Utilisateur qui correspond à la table de Utilisateurs - rôles qui correspond à Rôles qui correspond à Rôles-opérations qui correspond à une table de Opérations qui correspond à la table de Ressources . Si vous n'avez pas besoin de la granularité de Opérations éliminez ce tableau et mettez en correspondance vos Rôles a Ressources via une autre table pour gérer cette relation multiple.
La réponse à la question 2 est non. Entité ( Ressources ) dans la base de données Utilisateur table. A Utilisateur est mappée à un Ressources par le biais des relations que j'ai décrites ci-dessus.
La meilleure approche pour utiliser ce modèle et l'ensemble de l'architecture basée sur les demandes d'indemnisation consiste à ne pas attribuer de droits d'entrée à l'assuré. Rôles à vos méthodes à l'aide de l'option Attribut d'autorisation C'est ainsi que l'on procédait généralement dans le passé. Au lieu de cela, les Ressources y Fonctionnement à vos méthodes, ce qui dissocie votre politique de sécurité de votre application. Pour un modèle de cette approche, voir ClaimsPrincipalPermissionAttribute . Vous pouvez créer votre propre AuthorizeAttribute personnalisé qui utilise cette approche.
