碼上快樂

相關內容    簡體    繁體

【譯】Asp.Net Identity與Owin，到底誰是誰？

本文轉載自   查看原文   2017-11-03 14:42   1248    Role/ Asp.Net Identity/ Owin/ Identity/ Claim/ Asp.Net

送給正在學習Asp.Net Identity的你 ：-）

原文出自 trailmax 的博客AspNet Identity and Owin. Who is who.

Recently I have found an excellent question on Stackoverflow. The OP asks why does claim added to Idenetity after calling AuthenticationManager.SignIn still persist to the cookie.

最近我在StackOverflow發現一個非常好的（妙啊）問題，OP提出的問題是，在調用AuthenticationManager.SignIn之后再向Identity添加Claim ，這些后添加的Claim仍然被保存在了Cookies里。

The sample code was like this:

代碼是這樣的

ClaimsIdentity identity = UserManager.CreateIdentity(user, DefaultAuthenticationTypes.ApplicationCookie );

var claim1 = new Claim(ClaimTypes.Country, "Arctica");
identity.AddClaim(claim1);

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

var claim2 = new Claim(ClaimTypes.Country, "Antartica");
identity.AddClaim(claim2);

Yeah, why does claim2 is available after cookie is already set.

噢耶，為什么在已經設置cookie之后claim2仍然是有效的呢？

After much digging I have discovered that AspNet Identity framework does not set the cookie. OWIN does. And OWIN is part of Katana Project which has open source code. Having the source code available is always nice – you can find out yourself why things work or don’t work the way you expect.

在我深度挖掘之后，我發現 AspNet Identity framework 並沒有真的去設置cookie，是Owin做的。Owin是開源項目Katana的一部分（譯者注：katana微軟對於Owin的實現，Owin的實現還有其它的）。能看源代碼總是一件很棒的事，因為你能自己去尋找為什么事情是這樣的或者為什么結果和預期的不一致的答案。

In this case I have spent a few minutes navigating Katana project and how AuthenticationManager works. Turned out that SingIn method does not set a cookie. It saves Identity objects into memory until time comes to set response cookies. And then claims are converted to a cookie and everything magically works ：-)

在這件事里，我花了幾分鍾時間找到Katana的源碼尋找AuthenticationManager的工作原理。原來SignIng方法並沒有設置Cookie。直到設置相應cookie之前，它只是將Identity對象放在了內存里。然后 claims被轉換成cookie，並且，神奇的事情發生了：-D（應該是這么翻譯吧...）

譯者注:下面是SignIn的源碼，源碼地址

public void SignIn(AuthenticationProperties properties, params ClaimsIdentity[] identities)
{
    AuthenticationResponseRevoke priorRevoke = AuthenticationResponseRevoke;
    if (priorRevoke != null)
    {
        // Scan the sign-outs's and remove any with a matching auth type.
        string[] filteredSignOuts = priorRevoke.AuthenticationTypes
            .Where(authType => !identities.Any(identity => identity.AuthenticationType.Equals(authType, StringComparison.Ordinal)))
            .ToArray();
        if (filteredSignOuts.Length < priorRevoke.AuthenticationTypes.Length)
        {
            if (filteredSignOuts.Length == 0)
            {
                AuthenticationResponseRevoke = null;
            }
            else
            {
                AuthenticationResponseRevoke = new AuthenticationResponseRevoke(filteredSignOuts);
            }
        }
    }

    AuthenticationResponseGrant priorGrant = AuthenticationResponseGrant;
    if (priorGrant == null)
    {
        AuthenticationResponseGrant = new AuthenticationResponseGrant(new ClaimsPrincipal(identities), properties);
    }
    else
    {
        ClaimsIdentity[] mergedIdentities = priorGrant.Principal.Identities.Concat(identities).ToArray();

        if (properties != null && !object.ReferenceEquals(properties.Dictionary, priorGrant.Properties.Dictionary))
        {
            // Update prior properties
            foreach (var propertiesPair in properties.Dictionary)
            {
                priorGrant.Properties.Dictionary[propertiesPair.Key] = propertiesPair.Value;
            }
        }

        AuthenticationResponseGrant = new AuthenticationResponseGrant(new ClaimsPrincipal(mergedIdentities), priorGrant.Properties);
    }
}

This sparked another question. At the moment Identity does not have open source, but what is the role of OWIN in Identity and how Claims work here?

這引發了另一個問題，此時 Identity還沒有開源，但是Identity中OWIN的Role是什么，並且，Claims是如何工作（譯者注：發揮作用）的？

Turns out that Identity framework deals only with user persistence, password hashing, validating if the password is correct, sending out email tokens for password reset, etc. But Identity does not actually authenticate users or create cookies. Cookies are handled by OWIN.

原來Identity framework做的事只有用戶持久化存儲、密碼Hash、驗證密碼是否是正確的、為重置密碼發送帶有Token的電子郵件等等。但是identity 沒有真正的認證用戶或者創建Cookie。Owin在處理Cookie。

Take a look on this code for signing in:

我們來看一下SignIng的代碼：

public async Task SignInAsync(Microsoft.Owin.Security.IAuthenticationManager authenticationManager, ApplicationUser applicationUser, bool isPersistent)
{
    authenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);

    ClaimsIdentity identity = await UserManager.CreateIdentityAsync(applicationUser, DefaultAuthenticationTypes.ApplicationCookie);

    authenticationManager.SignIn(new Microsoft.Owin.Security.AuthenticationProperties() { IsPersistent = isPersistent }, identity);
}

Identity only creates ClaimsIdentity which you can study on ReferenceSource site. And ClaimsIdentity is part of .Net framework, not some nuget-package from the interwebz. Then this claimsIdentity is passed to OWIN AuthenticationManager where a callback is set to assign cookies on when time comes to write headers on the response.

Identity只是創建了ClaimsIdentity，你可以在ReferenceSource （譯者注：查看.Net源碼的地方，微軟官辦，沒保存的同學快快收藏吧！）上學習他的代碼。而且ClaimsIdentity是.Net Freamwork的一部分，不是從互聯網上下載的Nuget包（實在不懂interwebz是什么意思 Orz）。然后claimsIdentity被傳給了OWIN AuthenticationManager，（斷句）OWIN AuthenticationManager是設置在派送Cookie（assign cookies）上的一個Callcack回調，（斷句）這個assign cookies是放在一個什么東西上，當到了向Response寫Header的時候就搞這個東西（這句話太難翻譯了，你一定要看看原話，我不保證這句話翻譯正確 （：逃）

So far, so good, we have 3 parts here: Identity framework creating a ClaimsIdentity, OWIN creating a cookie from this ClaimsIdentity. And .Net framework which holds the class for ClaimsIdentity.

目前看來還不錯。我們知道了這里有3個部分：

  • Identity framework 創建了一個ClaimsIdentity，
  • Owin為ClaimsIdentity創建了cookie
  • 持有 ClaimsIdentity的class的是.Net framework

When in your classes you access ClaimsPrincipal.Current, you only use .Net framework, no other libraries are used. And this is very handy!

當你在你的代碼中訪問ClaimsPrincipal.Current時，你只用的了.Net framework，沒有其它庫（library）被用到，這是非常方便的。

Default Claims

Identity framework does a nice thing for you. By default it adds a number of claims to a principal when user is logged in. Here is the list:

Identity framework幫你做了很多有用的事。默認情況下，在用戶登錄的時候，她會添加一些claims到principal（譯者注：看一下Mvc中的HttpContext.User的類型，就是IPrincipal）。接下來是列表：

You can find the list of framework claim types on .Net Reference site. However, this list is not complete. You can make up your own claim types as you are pleased – this is just a string.

你能夠在.Net Reference網站上找到claim type的列表。然而，這個列表並不完整。如果你喜歡，你完全可以制造你自己的claim type，因為它只是一個字符串而已。

If you want to add your own claim types, I recommend to use your own notation for the claim types. Something like “MyAppplication:GroupId” and keep all the claim types in one class as constants:

如果你想添加你自己的claim type ，我建議你在claim type上加上你自己獨特的標記。比如：“MyAppplication:GroupId”，然后將它們作為 constants存在某個類里面。

public class MyApplicationClaimTypes
{
    public string const GroupId = "MyAppplication:GroupId";
    public string const PersonId = "MyAppplication:PersonId";
    // other claim types
}

This way you can always find where the claims are used and will not clash with the framework claim types. Unless the claim you use matches framework claim types exactly, like ClaimTypes.Email.

這種方式讓你能夠找到哪里引用了這些claims，並且不會和framework中的claim type發生沖突。除非你使用的claim type的framework中的claim type精確匹配，例如：ClaimTypes.Email。

Adding default claims 添加默認的claims

I always add user’s email to the list of claims. I do that on user sign-in, same way the first code snippet adds claim1 and claim2:

我總是使用和第一個添加claim1和claim2相同的方式在用戶登錄時將用戶的email添加到claims列表里。

public async Task SignInAsync(IAuthenticationManager authenticationManager, ApplicationUser applicationUser, bool isPersistent)
{
    authenticationManager.SignOut(
        DefaultAuthenticationTypes.ExternalCookie,
        DefaultAuthenticationTypes.ApplicationCookie);

    var identity = await this.CreateIdentityAsync(applicationUser, DefaultAuthenticationTypes.ApplicationCookie);

    // using default claim type from the framework
    identity.AddClaim(new Claim(ClaimTypes.Email, applicationUser.Email));

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

You can add your default claims to all users here as well. But there is IClaimsIdentityFactory class that is assigned in UserManager. There is only one method there:

你可可以向所有用戶添加默認的claims。但是在UserManager中有一個IClaimsIdentityFactory的類，它只定義了一個方法。

public interface IClaimsIdentityFactory<TUser, TKey> where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>
{
    /// <summary>
    /// Create a ClaimsIdentity from an user using a UserManager
    /// </summary>
    Task<ClaimsIdentity> CreateAsync(UserManager<TUser, TKey> manager, TUser user, string authenticationType);
}

Default AspNet Identity implementation creates ClaimsIdentity, adds the default claims described above, adds claims stored in the database for the user: IdentityUserClaims. You can override this implementation and slip-in your own logic/claims:

默認的Asp.Net Identity實現創建ClaimsIdentity，添加之前提到的默認claims，添加存儲在satabase中的屬於這個用戶的claims：IdentityUserClaims。你可以重寫這個實現類，然后放進你自己的 logic/claims.
public class MyClaimsIdentityFactory : ClaimsIdentityFactory<ApplicationUser, string>
{
public override async Task CreateAsync(UserManager<ApplicationUser, string> userManager, ApplicationUser user, string authenticationType)
{
var claimsIdentity = await base.CreateAsync(userManager, user, authenticationType); 

        claimsIdentity.AddClaim(new Claim("MyApplication:GroupId", "42"));

        return claimsIdentity;
    }
}

and assign it in UserManager:

將它賦值給UserManager：

public UserManager(MyDbContext dbContext)
    : base(new UserStore<ApplicationUser>(dbContext))
{
    // other configurations

    // Alternatively you can have DI container to provide this class for better application flexebility
    this.ClaimsIdentityFactory = new MyClaimsIdentityFactory();
}

正文結束

補充一些譯者的話

如果你注意到文中提到登陸的代碼authenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = isPersistent }, identity);
在新的Mvc項目中勾選個人身份認證時所生成的基本代碼已經變成了 var result = await SignInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, shouldLockout: false); ，我試過使用文中的方法，是可以正常登陸的。

因為最終SignInManager的PasswordSignInAsync方法幾經輾轉也調用了IAuthenticationManager實例的Sign方法完成登陸。


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 ASP.NET沒有魔法——Identity與Owin AspNet Identity 和 Owin 誰是誰 【譯】ASP.NET Identity Core 從零開始 【譯】Asp.Net Identity Cookies 格式化 MVC5 - ASP.NET Identity登錄原理 - Claims-based認證和OWIN MVC5 - ASP.NET Identity登錄原理 - Claims-based認證和OWIN ASP.NET Identity Owin+ASP.NET Identity淺析系列（二）擴展用戶屬性 Owin+ASP.NET Identity淺析系列（一）用戶登錄注冊 細說ASP.NET Core與OWIN的關系
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM