2016-02-26 20 views
5

Trong thiết lập middleware Asp.Net nhận dạng Auth ứng dụng của tôi của tôi cóCookieAuthenticationOptions.AuthenticationType được sử dụng để làm gì?

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

tôi đã sao chép này từ ứng dụng khác và tôi chỉ nhận thấy rằng nếu tôi bỏ ghi chú dòng AuthenticationType, đăng nhập thành công (tôi nhận được một thông báo thành công trong tôi logger được viết từ bộ điều khiển của tôi) nhưng luôn chuyển hướng trở lại màn hình đăng nhập.

Trong documentation for CookieAuthenticationOptions nó nói

Các AuthenticationType trong các tùy chọn tương ứng với tài sản IIdentity AuthenticationType. Giá trị khác có thể được chỉ định để sử dụng cùng một loại phần mềm trung gian xác thực nhiều hơn một lần trong một đường ống. (Được thừa kế từ AuthenticationOptions.)

Tôi thực sự không hiểu điều này có nghĩa là gì, tại sao điều này lại gây ra đăng nhập của tôi yêu cầu được chuyển hướng (sau khi đăng nhập thành công không ít hơn), cũng không phải tùy chọn này nào sẽ hữu ích cho.

Trả lời

4

Đây là một chuỗi và có thể là bất kỳ thứ gì. Nhưng đây là số nhận dạng cho loại xác thực. Và bạn có thể có nhiều loại xác thực: DB của bạn với người dùng, Google, Facebook, v.v. Theo tôi nhớ điều này được thêm vào làm xác nhận quyền sở hữu đối với cookie được tạo khi đăng nhập.

Bạn cần biết nhà cung cấp xác thực khi bạn đăng xuất người dùng. Nếu middleware xác thực của bạn được định nghĩa như thế này:

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

sau đó ký sử dụng ra bạn cần cùng chuỗi ma thuật: AuthenticationManager.SignOut("My-Magical-Authentication")

Cũng chuỗi này được thông qua vào ClaimsIdentity khi chính được tạo ra.Và không có AuthenticationType chính không thể xác thực 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); 
    } 
} 

Phương pháp này IsAuthenticated được sử dụng thông qua toàn bộ MVC mã cơ sở, với tất cả các cơ chế xác thực dựa vào này.

Về mặt lý thuyết, bạn có thể đăng nhập qua nhiều nhà cung cấp và chỉ đăng xuất một tài khoản duy nhất tại một thời điểm, để phần còn lại của nhà cung cấp vẫn được xác thực. Mặc dù tôi chưa bao giờ thử điều này.

Sử dụng khác mà tôi vừa tìm thấy - nếu bạn không cung cấp CookieName trong cấu hình phần mềm trung gian của mình, thì Options.CookieName = CookieAuthenticationDefaults.CookiePrefix + Options.AuthenticationType; (see second if statement in constructor).

Tôi chắc chắn có nhiều địa điểm được sử dụng hơn. Nhưng điều quan trọng nhất là cung cấp cho nó và nhất quán với tên hoặc bạn sẽ nhận được các lỗi nhỏ trong hệ thống xác thực.

4

Tôi không biết toàn bộ câu trả lời, nhưng tôi có một ví dụ về những gì nó sẽ hữu ích cho.

Tôi có trang web nhiều người thuê: trang web chạy dưới dạng một trường hợp đơn lẻ nhiều tên miền được liên kết với nó. Mỗi miền là một đối tượng thuê riêng biệt (với một nhóm người dùng riêng). Để thực hiện đăng nhập Facebook cho mỗi người thuê nhà, tôi cần một ứng dụng Facebook cho mỗi người thuê nhà. Để cấu hình này, tôi đã phải thiết lập một CallbackPath độc đáo một AuthenticationType độc ​​đáo cho mỗi người thuê nhà:

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

tôi nghĩ rằng nó cũng được sử dụng như một tên cookie, nhưng đó không phải là trường hợp cho một đăng nhập bên ngoài như FacebookAuthentication. Những gì tôi đã thông báo là giá trị này của AuthenticationType popped lên khi yêu cầu:

  1. các IdentityUserLogin.LoginProvider qua authenticationManager.GetExternalLoginInfoAsync()
  2. các AuthenticationDescription.AuthenticationType qua authenticationManager.GetExternalAuthenticationTypes() (có vẻ hợp lý ;-))
  3. các IdentityUserLogin.LoginProvider cho mỗi user.Logins (tương tự như 1)

Và cuối cùng nhưng không kém phần quan: giá trị của AuthenticationType được lưu trữ trong cơ sở dữ liệu cột AspNetU serLogins.LoginProvider.

2

Nếu bạn thiết lập một giải pháp asp.net tươi, tiêu chuẩn thiết lập mã (như trái ngược với các mã mà bạn đã copy từ ứng dụng khác) trong Startup.Auth bao gồm dòng AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

này tạo ra một cookie (với tên mặc định là .AspNet.ApplicationCookie), bạn có thể thấy nếu bạn nhìn vào danh sách cookie hoạt động của trình duyệt, được sử dụng (trong số những thứ khác) để kiểm tra xem Người dùng có được xác thực cho mọi yêu cầu hay không. Nếu cookie không có ở đó (hoặc Người dùng theo cách nào đó không được Xác thực), phần mềm trung gian sẽ chuyển hướng đến tuyến đường được chỉ định trong dòng của bạn LoginPath = new PathString("/Login/"),

Thực tế là dòng này được nhận xét trong mã của bạn và công trình ứng dụng của bạn cho thấy rằng có một số cấu hình không chuẩn khác trong mã của bạn để xác thực Người dùng. Nếu bạn bỏ ghi chú dòng này và đăng nhập thành công nhưng chuyển hướng trở lại để đăng nhập, điều này gợi ý rằng có một số xung đột giữa mã không chuẩn và phần mềm trung gian dẫn đến phần mềm trung gian xác định rằng Người dùng không được xác thực và được chuyển hướng trở lại LoginPath .

Tôi sẽ tìm hiểu xem có mã xác thực không chuẩn trong ứng dụng của bạn và xác định những gì cụ thể thực hiện hay không, và câu trả lời cho xung đột sẽ xuất hiện. Lời khuyên chung là không thay đổi mã xác thực tiêu chuẩn trừ khi bạn biết chính xác ý nghĩa của việc thực hiện điều này là gì (và nó có thể phức tạp, với nhiều bẫy cho người không tự nguyện).

Cụ thể cho câu hỏi của bạn, tùy chọn này không chỉ hữu ích, nó là nền tảng cho hoạt động chuẩn của phần mềm trung gian nhận dạng. Dường như bạn có mã không chuẩn trong ứng dụng của mình. Nếu vậy, bạn nên hoàn toàn xác định những gì nó làm (và nó có nghĩa là) liên quan đến bảo mật đăng nhập, hoặc trở lại mã nhận dạng tiêu chuẩn nếu bạn có thể.

Các vấn đề liên quan