web-dev-qa-db-ja.com

別のドメインのログインページ

私はOWIN認証に完全に慣れていないので、すべてがどのように機能するかを誤解しているに違いありませんが、どこにも記載されていません。

必要なのは、認証に中央ドメインを使用できることです。認証されていないときに誰かがapps.domain.comにアクセスしようとすると、accounts.domain.com/loginにリダイレクトされ、すべての認証が独自のドメインとアプリケーションに分離されます。これは、完全なURLを指定できるMVC 4フォーム認証では非常に簡単でしたが、OWINではそうではありません。

Startup.Auth.cs：

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

CookieDomainオプションを使用してCookieを設定する場合、ドメインを指定するのは簡単です。ただし、リダイレクト先のログインパスを指定する場合、それは現在のアプリケーションに関連している必要があるので、MVC 4フォーム認証でこれほど簡単であったことを実現するにはどうすればよいですか？

OWINの認証について深く理解していなかったため、2時間ほど検索しても、この問題に対処する方法は見つかりませんでした。

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);
    }
}

Apps.domain.comが可能な唯一のリターンURLベースである場合、context.Request.Uri.AbsoluteUriをcontext.Request.PathBase + context.Request.Path + context.Request.QueryStringで置き換えることを強く検討し、不正なリダイレクトからアプリを保護するために認証サーバーで絶対リターンURLを構築する必要があります。

お役に立てれば ;）

[〜＃〜] edit [〜＃〜]：context.RedirectUriプロパティを使用してリダイレクトを直接適用しない理由を自問するかもしれません。実際、ICookieAuthenticationProvider.ApplyRedirectは、ログインフローとログアウトフローに対応する複数のリダイレクトを担当します（そうですね、それは単一の責任の原則を破っています...）。しかし、さらに悪いことに、context.RedirectUriは、Cookieが効果的に送信されている場合、ログインフローの最初の認証エンドポイントの絶対URLまたは最終的なブラウザーの宛先（つまり、実際の相対「戻りURL」）を表すことができます。ブラウザに戻って... context.RedirectUriが絶対であり、登録されたcontext.Options.LoginPathに対応していることを確認する必要があるのはそのためです。

49
Kévin Chalet

https://github.com/IdentityServer/IdentityServer の例に取り組んでいますが、別の答えがあります。 https://www.scottbrady91.com/Identity-Server/Identity-Server-3-Standalone-Implementation-Part-2 の例では、スタンドアロンのIdPとCookieを使用するMVCアプリを表示しています認証。この例には401リダイレクトを機能させることは含まれていませんでしたが、私はある方法で偶然見つけました。

基本的なスキームは、ログオンのためにAccountControllerにアクションを作成することです。

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

これで、スタートアップで使用できるローカルURLができました。

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

また、401が表示される前にログオンしたいユーザーのために、メニューバーの[サインイン]にアクションリンクを配置できるという利点もあります。ここで行ったのは、認証されていないユーザーは、認証の取得方法からリソースを要求します。

7
Skip Saillors