web-dev-qa-db-fra.com

Meilleures pratiques pour les rôles et les revendications dans l'identité ASP.NET

Je suis complètement nouveau dans l'utilisation de claims dans ASP.NETIdentity et que vous souhaitez vous faire une idée des meilleures pratiques en matière d'utilisation de Roles and/or Claims.

Après toutes ces lectures, j'ai encore des questions comme ...

Q: N'utilisons-nous plus de rôles?
Q: Si oui, pourquoi les rôles sont-ils toujours offerts?
Q: Devrions-nous utiliser uniquement les revendications?
Q: Devrions-nous utiliser les rôles et les revendications ensemble?

Ma pensée initiale est que nous "devrions" les utiliser ensemble. Je vois Claims comme des sous-catégories du Roles qu’ils supportent.

PAR EXEMPLE:
Rôle: Comptabilité
Revendications : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

Q: Sont-ils destinés à s'exclure mutuellement?
Q: Ou vaut-il mieux traiter les réclamations SEULEMENT et vous qualifier pleinement?
Q: Quelles sont donc les meilleures pratiques ici?

EXEMPLE: Utiliser les rôles et les revendications ensemble
Bien sûr, vous devrez écrire votre propre logique d'attribut pour cela ...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

EXEMPLE: Qualifiez entièrement vos demandes

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}
asp.net-mvcrolesclaims-based-identity
83
Prisoner ZERO

Un rôle est une catégorie symbolique qui regroupe des utilisateurs partageant les mêmes niveaux de privilèges de sécurité. L'autorisation basée sur les rôles nécessite d'abord d'identifier l'utilisateur, puis de déterminer les rôles auxquels il est affecté, et enfin de comparer ces rôles aux rôles autorisés à accéder à une ressource.

En revanche, une réclamation est un droit de l'utilisateur de s'identifier. En d'autres termes, "je suis autorisé à le faire parce que j'ai cette réclamation.". En règle générale, l'autorisation basée sur les revendications englobe l'autorisation basée sur les rôles. Pour être précis, l'appartenance à un rôle est déterminée en fonction de l'identité et l'identité n'est qu'un type de droit à la valeur d'une revendication. Les rôles sont essentiellement un type de revendication très spécifique, à savoir "Comme mon nom d'utilisateur est le suivant, je suis membre de ce rôle. Parce que je suis membre de ce rôle, j'ai accès à cette ressource.".

Vous pouvez utiliser les deux de concert, ou utiliser un type dans certaines situations et l’autre dans d’autres. Cela dépend principalement de l'interopérabilité avec d'autres systèmes et de votre stratégie de gestion. Par exemple, il peut être plus facile pour un responsable de gérer une liste d'utilisateurs assignés à un rôle que de gérer les personnes ayant une revendication spécifique attribuée. Les revendications peuvent être très utiles dans un scénario RESTful dans lequel vous pouvez attribuer une revendication à un client, lequel peut ensuite présenter la revendication pour autorisation au lieu de transmettre le nom d'utilisateur et le mot de passe pour chaque demande.

71
Claies

Comme @Claies l'a parfaitement expliqué, les revendications pourraient être plus descriptives et constituer un type de rôle profond. Je pense à eux comme à vos identifiants de rôles. J'ai un identifiant de gym, alors j'appartiens au rôle de membre. Je suis aussi dans les leçons de kickboxing, donc j'ai une revendication pour eux; un identifiant de kickboxing. Ma candidature nécessiterait la déclaration d'un nouveau rôle correspondant à mes droits de membre. Au lieu de cela, j'ai des identifiants pour chaque chose que je peux faire au gymnase; au lieu de beaucoup de nouveaux types d'adhésion. C'est pourquoi les revendications me conviennent mieux.

Il existe une excellente vidéo d’explication de Barry Dorrans, qui évoque l’avantage d’utiliser des revendications par rapport aux rôles. Il déclare également que les rôles sont toujours dans .NET pour la compatibilité ascendante. La vidéo est très informative sur le fonctionnement des revendications, des rôles, des stratégies, des autorisations et de l'authentification.

Vous pouvez le trouver ici: Autorisation ASP.NET Core avec Barr Dorrans

23
Jonathan Ramos

Ayant utilisé diverses techniques d'authentification et d'autorisation au fil des décennies, mon application MVC actuelle utilise la méthodologie suivante.

Les réclamations sont utilisées pour toutes les autorisations. Les utilisateurs se voient attribuer un rôle (plusieurs rôles sont possibles mais je n’en ai pas besoin) - plus ci-dessous.

Comme il est de pratique courante, une classe d'attributs ClaimsAuthorize est utilisée. Étant donné que la plupart des actions du contrôleur sont CRUD, la procédure de génération de code-tout d'abord comporte une routine qui itère toutes les actions du contrôleur et crée des types de réclamation pour chaque attribut d'action de contrôleur de lecture/édition/création/suppression. Par exemple. de,

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

Pour une utilisation dans une vue MVC, une classe de contrôleurs de base présente les éléments de sac de vues

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

Pour les menus de site Web et les autres actions non liées au contrôleur, j'ai d'autres revendications. Par exemple. si un utilisateur peut visualiser un champ monétaire particulier.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

Où se situent les rôles?

J'ai une table qui lie un rôle à un ensemble (par défaut) de revendications. Lors du paramétrage de l'autorisation d'utilisateur, la valeur par défaut est de donner à l'utilisateur les revendications de son rôle. Chaque utilisateur peut avoir plus ou moins de revendications que la valeur par défaut. Pour simplifier l’édition, la liste des revendications est affichée par contrôleur et par action (rangées), les autres revendications étant ensuite répertoriées. Les boutons sont utilisés avec un peu de Javascript pour sélectionner un ensemble d’actions afin de minimiser le "clic" requis pour sélectionner les revendications. Lors de l'enregistrement, les revendications des utilisateurs sont supprimées et toutes les revendications sélectionnées sont ajoutées. L'application Web ne charge les revendications qu'une seule fois. Par conséquent, toute modification doit être rechargée dans ces données statiques.

Les responsables peuvent donc sélectionner les revendications de chaque rôle et celles d'un utilisateur après leur avoir attribué un rôle, ainsi que les revendications par défaut. Le système ne compte qu'un petit nombre d'utilisateurs. La gestion de ces données est donc simple.

6
pixelda

Pour comprendre la différence entre les rôles et les revendications, vous devez faire face à la limitation des rôles et vous rendre compte de la manière dont les revendications se règlent sur ces problèmes. Nous vous présentons donc 2 scénarios pour reconnaître le pouvoir des revendications lorsque le rôle ne peut pas résoudre ces problèmes:

1- Votre site a deux modules (pages, service ..etc): le premier module pour enfant (moins de 18 ans), l'autre pour adulte (plus de 18 ans), votre identité d'utilisateur a un anniversaire.

vous devez créer une politique sur cette revendication pour que l'autorisation de chaque module soit donnée sur cette valeur. Si l'utilisateur est âgé de plus de 18 ans, il peut accéder au module adulte et pas avant cet âge.

Le rôle est un type de données booléen que vous pouvez avoir ou ne pas avoir. Le rôle n'a pas de valeurs maltées

2- votre site a un rôle d'utilisateur et vous ne pouvez pas empêcher l'accès des utilisateurs d'effectuer des travaux de maintenance sans changer le code

dans les revendications, vous pouvez créer une règle UnderConstrain qui, si l'utilisateur n'est pas en mesure d'afficher la page, donne la propriété authorize for role user.

1
mohammed rashed