ASP.NET 3.5 Fournisseurs de rôles multiples

Question

J'ai une application ASP.NET 3.5 que j'ai récemment étendue avec plusieurs fournisseurs de rôles et d'appartenances pour "attacher" une deuxième application au sein de cette application. Je n'ai pas d'accès direct à la configuration IIS, donc je ne peux pas la décomposer dans un répertoire d'application séparé. Cela dit, j'ai séparé avec succès les connexions; Cependant, après que je me connecte, je suis capable de vérifier les groupes auxquels l'utilisateur appartient à travers des routines de rôles personnalisées, et je suis capable d'avoir des noms d'utilisateur identiques avec des mots de passe différents pour les deux "applications". Le problème que je rencontre est quand je crée un utilisateur avec un nom d'utilisateur identique à l'autre adhésion (qui utilise les rôles web.config sur les répertoires), je suis en mesure de passer les URL manuellement à l'autre application, et il récupère le nom d'utilisateur et charge les rôles pour cette application. Évidemment, c'est mauvais, car il permet à un utilisateur de créer un nom d'utilisateur de quelqu'un qui a accès à l'autre application, et de traverser dans l'autre application avec les rôles de l'autre utilisateur.

Comment puis-je atténuer cela? Si je suis limité à une application avec laquelle travailler, avec plusieurs fournisseurs de rôles et d'appartenances, et que le cookie d'authentification stocke le nom d'utilisateur qui est apparemment transférable, y a-t-il quelque chose que je puisse faire?

Je me rends compte que la situation n'est pas idéale, mais ce sont les limitations imposées pour le moment.

Exemple d'authentification (lors de la validation):

FormsAuthentication.SetAuthCookie(usr.UserName, false); 

Ce cookie doit être basé sur le jeton d'utilisateur Je soupçonne plutôt que UserName afin de séparer les deux fournisseurs? Est-ce possible?

Answer 1

Peut-être pas la réponse que je préfère aller avec, mais j'ai pu séparer les deux en ayant une application utilise le nom d'utilisateur pour le cookie auth, et l'autre utilisation du ProviderUserKey (guid) . De cette façon, le cookie d'authentification ne serait pas reconnu d'une "application" à l'autre.

FormsAuthentication.SetAuthCookie(user.ProviderUserKey.ToString(), false); 

Cela me nécessaire pour gérer les choses un peu bizarrement, mais il est descendu simplement d'ajouter des méthodes d'extension et la manipulation d'un grand nombre de services publics de membres à travers ma propre classe (que je faisais de toute façon).

ex. Méthode d'extension:

public static string GetUserName(this IPrincipal ip) 
{ 
    return MNMember.MNMembership.GetUser(new Guid(ip.Identity.Name), false).UserName; 
} 

Où MNMember est une classe statique, MNMembership renvoie le fournisseur d'appartenances secondaire et GetUser est la fonction standard des fournisseurs d'appartenances.

var validRoles = new List<string>() { "MNExpired", "MNAdmins", "MNUsers" }; 
      var isValidRole = validRoles.Intersect(uroles).Any(); 
      if (isValidRole) 
      { 
       var userIsAdmin = uroles.Contains("MNAdmins"); 
       if (isAdmin && !userIsAdmin) 
       { 
        Response.Redirect("/MNLogin.aspx"); 
       } 
       else if (!userIsAdmin && !uroles.Contains("MNUsers")) 
       { 
        Response.Redirect("/MNLogin.aspx"); 
       }... 

Où isAdmin vérifie si un sous-répertoire apparaît dans le chemin.

Semble hacky, mais semble également fonctionner. Edit: Maintenant que je n'utilise pas le nom d'utilisateur comme token, je devrais être capable de revenir à l'utilisation de web.config pour la sécurité du répertoire, ce qui signifie que le hack master page devrait pouvoir être supprimé. (théoriquement?

Édition 2: Nope - asp.net utilise le cookie d'authentification de nom d'utilisateur pour résoudre les rôles spécifiés dans le fichier web.config.

Answer 2

Avez-vous essayé de spécifier l'attribut applicationName dans votre chaîne de connexion d'appartenance?

https://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx?f=255&MSPPError=-2147217396