Asp.net MVC 5 semble avoir laissé de côté l'utilisation de la classe AuthorizeAttribute où vous pouvez créer un attribut d'autorisation personnalisé en implémentant la classe AuthorizeAttribute, remplacer ses méthodes et masquer la propriété SiteRole au cas où vous vouliez cuire dans vos propres rôles. Tous les exemples que j'ai vus suggèrent d'utiliser OWIN ou le cadre d'identité. S'agit-il des deux seules façons de faire l'authentification et l'autorisation dans le nouveau cadre ASP.Net?. Vais-je manquer quelque chose si je le fais à l'ancienne? Je ne veux pas que le framework crée toutes les tables d'utilisateurs et de rôles pour moi. Que faire si je souhaite ajouter un utilisateur et une table de rôles existants à une nouvelle application?
De plus, je ne vois pas vraiment de besoin d'intégration sociale dans chaque application pour l'instant et je ne pense pas que j'en aurai également besoin immédiatement. Existe-t-il un article qui explique le démarrage avec un strict minimum en utilisant un attribut d'autorisation personnalisé, puis ajoute les nouvelles fonctionnalités d'authentification. Je veux quelque chose qui explique essentiellement tout l'encombrement dans un projet nouvellement créé sans authentification ou authentification utilisateur individuel sélectionné.
Vous pouvez toujours personnaliser AuthorizeAttribute dans MVC 5 à l'aide de ASP.NET Identity. Il y a un exemple de cela dans le SimpleSecurity Project . Voici un AuthorizedAttribute personnalisé que vous pouvez utiliser pour les contrôleurs et voici un AuthorizeAttribute personnalisé que vous pouvez utiliser pour les API Web . Le concept derrière ces AuthorizeAttributes personnalisés est de découpler votre modèle de sécurité de votre modèle d'application qui est discuté ici . Celui pour les API Web est également prend en charge l'authentification de base .
Le pipeline de sécurité a changé avec l'introduction d'OWIN et j'ai rencontré quelques problèmes avec le comportement d'AutorizeAttribute pour les API Web, qui est discuté ici .
Vous trouverez également des exemples dans le projet SimpleSecurity sur le portage de l'ancien fournisseur d'adhésion appelé SimpleMembership vers MVC 5. Certains des les problèmes avec le processus de mise à niveau sont discutés ici . Je l'ai cependant fait fonctionner pour que vous puissiez utiliser l'ancienne implémentation du fournisseur d'adhésion. Mais ma recommandation serait d'aller avec l'identité ASP.NET car c'est la voie à suivre que Microsoft prendra en charge, c'est une architecture plus flexible, et elle élimine la plupart des problèmes trouvés dans l'ancien fournisseur d'appartenance) implémentations .
Ben Foster propose une série en deux parties qui vous guide dans la mise en œuvre de l'authentification basée sur les cookies avec ASP.NET Identity à partir de zéro, en commençant par une nouvelle application Web sans authentification sélectionnée. Suivez "ASP.NET Identity Stripped Bare" Partie 1 et Partie 2 .
utilisez l'attribut Authorize suivant pour gérer les accès non autorisés lorsque l'utilisateur est déjà authentifié.
public class LoggedOrAuthorizedAttribute : AuthorizeAttribute
{
public LoggedOrAuthorizedAttribute()
{
View = "error";
Master = String.Empty;
}
public String View { get; set; }
public String Master { get; set; }
public override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
CheckIfUserIsAuthenticated(filterContext);
}
private void CheckIfUserIsAuthenticated(AuthorizationContext filterContext)
{
// If Result is null, we’re OK: the user is authenticated and authorized.
if (filterContext.Result == null)
return;
// If here, you’re getting an HTTP 401 status code. In particular,
// filterContext.Result is of HttpUnauthorizedResult type. Check Ajax here.
if (filterContext.HttpContext.User.Identity.IsAuthenticated)
{
if (String.IsNullOrEmpty(View))
return;
var result = new ViewResult {ViewName = View, MasterName = Master};
filterContext.Result = result;
}
}
}