ASP.NET MVC Identité login sans mot de passe

J'ai été reçu pour mission de la modification d'une ASP.NET MVC de l'application de telle manière que le surf à myurl?nom d'utilisateur=xxxxxx serait automatiquement journal de l'utilisateur xxxxxx, sans demander de mot de passe.

Je l'ai déjà fait, il est très clair que c'est une idée terrible pour beaucoup liées à la sécurité, des raisons et des scénarios, mais les personnes en charge sont déterminés. Le site ne serait pas disponible publiquement.

Donc: est-il possible de vous connecter sans mot de passe, par exemple, l'extension de la Microsoft.AspNet.L'identité.UserManager et la modification de la AccountController?

Code:

  var user = await _userManager.FindAsync(model.UserName, model.Password);
                    if (user != null && IsAllowedToLoginIntoTheCurrentSite(user))
                    {
                        user = _genericRepository.LoadById<User>(user.Id);
                        if (user.Active)
                        {
                            await SignInAsync(user, model.RememberMe);

_userManager détient une instance de Microsoft.AspNet.L'identité.UserManager.

et SignInAsync():

 private async Task SignInAsync(User user, bool isPersistent)
    {
        AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);
        var identity = await _userManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
        if (user.UserGroupId.IsSet())
            user.UserGroup = await _userManager.Load<UserGroup>(user.UserGroupId);

        //adding claims here ... //

        AuthenticationManager.SignIn(new AuthenticationProperties { IsPersistent = isPersistent }, new CustomClaimsIdentity(identity));
    }

AuthenticationManager serait OwinSecurity.

Montrez-nous votre login code 🙂
...et bien sûr, aucune entreprise n'a jamais de problèmes avec les menaces internes toux Snowden toux. Quant à votre question, oui, c'est facile. Rendre les choses moins sûr est toujours. Je serais tenté de définir tous les mot de passe sur une chaîne vide et de l'utiliser de manière implicite (rapides " n sale, mais il va travailler et faire le point que votre sécurité est sans valeur en même temps). Si vous voulez le faire "correctement", vous pouvez sous-classe auth fournisseurs
J'ai ajouté le code pertinent.
Les comptes d'utilisateur et les mots de passe devraient rester comme ils sont. L'utilisateur normal/passer à la page de connexion doit rester en place. L'URL que j'ai parlé de serait tout simplement une porte dérobée.
Si vous laissez vos comptes d'utilisateurs avec des mots de passe qui peut être sauté à l'aide d'une "magie" de l'url, vous êtes en donnant un faux sentiment de sécurité. C'est le pire genre de conception du système. Si vous ne pouvez pas convaincre votre patron c'est une mauvaise idée, envisager de parler à quelqu'un de la chaîne de l'aversion au risque (et compétent).

OriginalL'auteur Bjorn | 2015-01-23

  1. 52

    Vous avez juste besoin d'utiliser le usermanager pour trouver l'utilisateur par son nom. Si vous avez un enregistrement, il suffit de s'inscrire.

        public ActionResult StupidCompanyLogin()
    {

        return View();
    }

    [HttpPost]
    //[ValidateAntiForgeryToken] - Whats the point? F**k security 
    public async Task<ActionResult> StupidCompanyLogin(string name)
    {

        var user = await UserManager.FindByNameAsync(name);

        if (user != null)
        {

            await SignInManager.SignInAsync(user, true, true);
        }

        return View();
    }
    Génial les noms d'action!
    Elle a effectivement travaillé, je pensais que ce serait plus compliqué. Merci d'aider un débutant. Pour une raison que je ne suis pas heureux de creuser ce trou de sécurité fonctionne.
    Pas de problème, assurez-vous de couvrir votre retour au travail!
    Ce n'est pas "stupide", comme il peut sembler. Pour l'authentification en mode Mixte vous avez besoin d'un deuxième site Web qui permettrait de connecter en tant qu'utilisateur de Windows et de passer en quelque sorte ses lettres de noblesse à la site Web avec des Formulaires d'Authentification. Depuis, de connexion de Windows, nous savons probablement rien de plus qu'un nom d'utilisateur, nous pouvons passer ce nom d'utilisateur et la force de la connexion d'un utilisateur avec le nom d'utilisateur uniquement. Certains de chiffrement ajoutée et de contrôle où l'appel provient d', ou une tentative d'utiliser le cookie défini par le deuxième de l'Authentification Windows application pourrait contribuer à accroître la sécurité. Afin de ne pas "stupide".
    Dans mon cas, c'était une question de mise en œuvre d'un "login" pour un admin pour accéder à un service du portail en tant qu'utilisateur spécifique. Par la mise en œuvre rapide personnalisé "se connecter" mot de passe de vérifier, en ouvrant une session en tant qu'utilisateur sans nécessiter explicite de mot de passe, j'ai été capable de faire cela très facilement, sans avoir à creuser dans des fournisseurs d'appartenance (certes, un fournisseur d'appartenances personnalisé aurait été une solution plus robuste sur le long terme)

    OriginalL'auteur heymega