web-dev-qa-db-fra.com

Page de connexion sur un domaine différent

Je suis complètement nouveau dans l'authentification OWIN, et je dois mal comprendre comment tout fonctionne, mais je ne trouve cela mentionné nulle part.

Tout ce que je veux, c'est pouvoir utiliser un domaine central pour l'authentification. Si quelqu'un essaie d'accéder à apps.domain.com lorsqu'ils ne sont pas authentifiés, ils seront redirigés vers accounts.domain.com/login afin que toute l'authentification soit séparée dans son propre domaine et application. C'était très facile avec l'authentification par formulaires MVC 4 où vous pouvez spécifier une URL complète, mais cela ne semble pas être avec OWIN.

Dans Startup.Auth.cs:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    LoginPath = new PathString("/account/login")
}

Il est facile de spécifier le domaine lors de la configuration du cookie avec l'option CookieDomain. Cependant, lorsque vous spécifiez le chemin de connexion vers lequel rediriger, il doit être relatif à l'application actuelle, alors comment dois-je faire pour accomplir ce qui était si facile dans l'authentification par formulaires MVC 4?

Sans aller trop loin dans le sens de l'authentification OWIN, je n'ai rien trouvé pour y remédier après quelques heures de recherche.

c#asp.netasp.net-mvcasp.net-mvc-5owin
39
wired_in
public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            AuthenticationMode = AuthenticationMode.Active,
            LoginPath = new PathString("/account/login"),
            LogoutPath = new PathString("/account/logout"),
            Provider = new CookieAuthenticationProvider
            {
                OnApplyRedirect = ApplyRedirect
            },
        });
    }

    private static void ApplyRedirect(CookieApplyRedirectContext context)
    {
        Uri absoluteUri;
        if (Uri.TryCreate(context.RedirectUri, UriKind.Absolute, out absoluteUri))
        {
            var path = PathString.FromUriComponent(absoluteUri);
            if (path == context.OwinContext.Request.PathBase + context.Options.LoginPath)
            {
                context.RedirectUri = "http://accounts.domain.com/login" +
                    new QueryString(
                        context.Options.ReturnUrlParameter,
                        context.Request.Uri.AbsoluteUri);
            }
        }

        context.Response.Redirect(context.RedirectUri);
    }
}

Si apps.domain.com est la seule base d'URL de retour possible, vous devriez sérieusement envisager de remplacer context.Request.Uri.AbsoluteUri Par context.Request.PathBase + context.Request.Path + context.Request.QueryString Et de créer une URL de retour absolue dans votre serveur d'authentification pour protéger vos applications contre les redirections abusives.

J'espère que cela t'aides ;)

MODIFIER : vous pourriez vous demander pourquoi je n'applique pas directement la redirection en utilisant la propriété context.RedirectUri. En fait, ICookieAuthenticationProvider.ApplyRedirect Est responsable de plusieurs redirections, correspondant aux flux de connexion et de déconnexion (oui, je sais, il casse le principe de responsabilité unique ...). Mais il y a encore pire: context.RedirectUri Peut représenter l'URL absolue du point de terminaison d'authentification au début du flux de connexion ou la destination finale du navigateur (c'est-à-dire la véritable "URL de retour" relative) lorsque le cookie est effectivement renvoyé au navigateur ... c'est pourquoi nous devons nous assurer que context.RedirectUri est absolu et correspond au context.Options.LoginPath enregistré.

49
Kévin Chalet

Je travaille à travers les exemples pour https://github.com/IdentityServer/IdentityServer et j'ai une réponse différente. Dans l'exemple à https://www.scottbrady91.com/Identity-Server/Identity-Server-3-Standalone-Implementation-Part-2 ils montrent une application MVC qui utilise un IdP autonome et des cookies authentification. L'exemple n'a pas inclus le fonctionnement des redirections 401, mais j'ai trébuché sur un chemin.

Le schéma de base consiste à créer une action dans le AccountController pour se connecter.

public ActionResult SignIn() {
  // set up some bookkeeping and construct the URL to the central auth service
  return Redirect(authURL);
}

Vous avez maintenant une URL locale qui peut être utilisée dans le démarrage

public class Startup {
  public void Configuration(IAppBuilder app) {
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
      AuthenticationType = "Cookies",
      LoginPath = new PathString("/Account/SignIn")
    });
}

Vous avez également l'avantage supplémentaire que vous pouvez mettre un lien d'action vers la connexion dans la barre de menus, pour les personnes qui souhaitent se connecter avant qu'il n'y ait un 401. Ce que nous avons fait ici est découplé de la décision de quoi faire lorsqu'un l'utilisateur non identifié demande une ressource de la façon dont l'authentification est obtenue.

7
Skip Saillors