Comment séparer les gros cookies dans l'identité ASP.NET en une plus petite pour permettre de nombreuses revendications?

Question

Je travaille sur un prototype d'une autorisation de réclamation pour notre application MVC. Nous utilisons l'identité ASP.NET pour l'authentification.

Nous aimerions avoir une réclamation pour chaque action du contrôleur, puis donner / supprimer des affirmations des utilisateurs afin que nous ayons un contrôle très fin sur qui peut aller où.

Notre application a déjà 800 actions et continue de croître. J'ai fait une petite application de test pour voir comment ce nombre de réclamations peut être traitée. Et courir dans un problème: Les cookies sont limités à 4092 octets .

et avoir un grand nombre de réclamations augmente le cookie d'authentification d'identité. Environ 600 réclamations avec des noms / valeurs abrégées (5 caractères chacun) donnez-moi de la taille de cookie sur 4K et que ce nombre de revendications ne peut tout simplement pas se connecter - Cookie ne peut pas être défini dans un navigateur.

et 600 revendications n'est pas une limite pour notre application. Nous aurons probablement plus besoin que cela.

existe-t-il un moyen de séparer Auth-Cookie en quelques biscuits plus petits?

P.s. Si vous êtes curieux, voici mon Code des réclamations "Profiler" avec le reste du projet .

p.p.s. Je connais des conséquences sur la performance des grands cookies. Ne pas s'inquiéter à ce sujet juste maintenant.

update actuellement il n'y a pas de solution de la boîte à ma réponse. Mais on dirait que je ne suis pas le seul avec ce problème. Microsoft.Owin gère l'auth-cookie. Et code source actuel pour owin.cokies a chunkingcookiemanager qui est affecté par défaut dans CookieAuthenticationMiddleware < / a>.

Mauvaise nouvelle que ce code est très frais (a été enregistré le 10 juillet 2014, seulement 20 jours). Il est disponible via une pré-version de Nuget Microsoft.owin .Security.cokies . Pas sûr que je voudrais utiliser RC2 dans le site de production.

Tout autre moyen?

Answer 1

Je n'ai pas résolu la question directe. Le cookie est trop grand et il restera grand avec un grand nombre ou des réclamations. Owin v3.0 (actuellement en RC2, pas prêt à la production) a un moyen de décoller les biscuits en plus petits. Mais de gros biscuits sont juste mauvais. Donc, je garde des sinistres uniquement côté serveur.

J'ai eu un Discussion sur le forum d'identité et trouvé Cette question qui répond à mes questions complètement. Baser la question, j'ai fait ma propre solution et prototypé une petite application MVC: https://github.com/ Trailmax / revendicationAuthorisation .

Le noyau de la solution est dans Routine de démarrage et il y a un Filtre MVC qui vérifie si les demandes requises sont disponibles pour l'utilisateur.

Answer 2

Vous utilisez de manière incorrecte des revendications.Les réclamations représentent l'identité de l'utilisateur et non les actions qu'elles sont autorisées à effectuer.Vous rencontrez des problèmes car vous traitez des réclamations comme une maison pour les autorisations utilisateur.Vous devriez vraiment trouver un moyen de séparer les deux dans votre application.

à la mode MVC, cela créerait un attribut d'autorisation personnalisé, d'obtenir l'identité de l'utilisateur à partir du cookie de réclamation et de vérifier que l'identité de l'utilisateur peut exécuter une action.

Voir les questions connexes ci-dessous.

restreindre l'accès aux enregistrements.Les autorisations basées sur la revendication sont-elles une bonne idée

Autorisation de réclamations pour des ressources spécifiques

Answer 3

Vous devez utiliser le rôle

[Authorize(Roles = "Admin, Role1")]
  public ActionResult Index(string id)
{....}
[Authorize(Roles = "Admin, Role2")]
  public ActionResult Index2(string id)
{....}
[Authorize(Roles = "Admin, Role1, Role3")]
  public ActionResult Index3(string id)
{....}