2016-02-26 114 views
5

在我的應用程序的Asp.Net身份驗證的中間件設置我有什麼是CookieAuthenticationOptions.AuthenticationType用於?

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
    LoginPath = new PathString("/Login/"), 
    //AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
    Provider = new CookieAuthenticationProvider { 
    OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<MyUserManager, MyUser>(
         TimeSpan.FromMinutes(30), 
         (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie) 
        ), 
    }, 
}); 

我從另一個應用程序複製這一點,我剛剛注意到,如果我取消了AuthenticationType線,登錄成功(我得到了一個成功的消息我記錄器從我的控制器寫入),但始終重定向回登錄屏幕。

documentation for CookieAuthenticationOptions它說

的AuthenticationType在選項對應的IIdentity AuthenticationType屬性。不同的值可能會使用相同的身份驗證的中間件類型不止一次在管道進行分配。(繼承自AuthenticationOptions。)

我真的不明白這是什麼意思,爲什麼會導致我的登錄請求重定向(成功登錄後不少於),也沒有什麼對此有用。

回答

4

這是一個字符串,可以是任何東西。但這是認證類型的標識符。您可以擁有多種身份驗證類型:包含用戶,Google,Facebook等的數據庫。據我所知,這是在登錄時添加爲生成的cookie的聲明。

當您簽出用戶時,您需要了解身份驗證提供程序。如果您的驗證中間件的定義是這樣的:

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
     LoginPath = new PathString("/Login/"), 
     AuthenticationType = "My-Magical-Authentication", 
     // etc... 
     }, 
    }); 

然後簽署用戶出你需要的一樣神奇的字符串:AuthenticationManager.SignOut("My-Magical-Authentication")

也是創建主體時該字符串傳遞到ClaimsIdentity。和無AuthenticationType主要不能被認證because

/// <summary> 
/// Gets a value that indicates whether the identity has been authenticated. 
/// </summary> 
/// 
/// <returns> 
/// true if the identity has been authenticated; otherwise, false. 
/// </returns> 
public virtual bool IsAuthenticated 
{ 
    get 
    { 
    return !string.IsNullOrEmpty(this.m_authenticationType); 
    } 
} 

此方法IsAuthenticated通過整個MVC編碼基數使用,依靠這種所有認證機制。

理論上,您也可以通過多個提供者登錄,並且一次僅註銷其中一個,而其他提供者仍然通過身份驗證。雖然我從來沒有嘗試過。

我剛剛發現的另一種用法 - 如果您在中間件配置中未提供CookieName,那麼Options.CookieName = CookieAuthenticationDefaults.CookiePrefix + Options.AuthenticationType;see second if statement in constructor)。

我確定有更多的地方使用它。但最重要的是提供它並與名稱保持一致,否則您將在身份驗證系統中發現微妙的錯誤。

4

我不知道整個答案,但我有一個例子,它是什麼是有用的。

我有一個多租戶網站:該網站作爲單個實例運行多個域鏈接到它。每個域都是獨立的租戶(具有單獨的一組用戶)。爲了實現每個租戶的Facebook登錄,我需要每個租戶的Facebook應用程序。要配置此,我不得不設置一個唯一的CallbackPath 每個租戶的唯一AuthenticationType:

var facebookOptions = new FacebookAuthenticationOptions 
{ 
    AuthenticationType = "Facebook-{tenantID}", 
    CallbackPath = new PathString($"/signin-facebook-{tenantID}") 
} 

我認爲它也被用來作爲一個cookie的名字,但是這並不像FacebookAuthentication外部登錄的情況。我也注意到的是,當請求AuthenticationType的這個值彈出:

  1. 通過authenticationManager.GetExternalLoginInfoAsync()的IdentityUserLogin.LoginProvider
  2. 通過authenticationManager.GetExternalAuthenticationTypes()(在AuthenticationDescription.AuthenticationType似乎是合乎邏輯;-) )
  3. 的IdentityUserLogin.LoginProvider每個user.Logins(類似於1)

最後但並非最不重要的:AuthenticationType的值被存儲在數據庫中的列AspNetU serLogins.LoginProvider。

2

如果設置了一個新鮮asp.net溶液,標準的設置代碼(相對於從其他應用中複製的代碼)在Startup.Auth 包括AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

這產生了cookie(默認名稱爲.AspNet.ApplicationCookie),您可以查看是否查看瀏覽器的活動cookie列表,該列表用於檢查用戶是否對每個請求進行身份驗證。如果cookie不存在(或者用戶未通過身份驗證),則中間件將重定向到您的線路中指定的路線LoginPath = new PathString("/Login/"),

此行在您的代碼和您的應用程序中註釋掉的事實表明,在您的代碼中還有一些其他非標準配置可用於對用戶進行身份驗證。如果取消註釋此行並登錄成功但重定向回登錄,則表明非標準代碼和中間件之間存在一些衝突,導致中間件確定用戶未通過身份驗證,並被重定向回LoginPath 。

我會尋求在你的應用中是否存在非標準的認證碼,並確定具體做什麼,並且衝突的答案應該出現。一般的建議是不要改變標準的認證碼,除非你確切地知道這樣做的意義是什麼(並且它會變得複雜,對於粗心大意有很多陷阱)。

具體到您的問題,這個選項不僅僅是有用的,它是標識中間件標準操作的基礎。您的應用中似乎有非標準的代碼。如果是這樣,您應該完全確定它在登錄安全性方面的功能(以及它的含義),或者如果可以的話,還原爲標準的身份代碼。