.NET Core Identity Server 4 Authentication VS Identity Authentication

ฉันกำลังพยายามทำความเข้าใจวิธีที่เหมาะสมในการตรวจสอบสิทธิ์ใน ASP.NET Core ฉันได้ดูทรัพยากรหลายอย่าง (ซึ่งส่วนใหญ่ล้าสมัย)

• Simple-Implementation-Of-Microsoft-Identity

• บทนำสู่การพิสูจน์ตัวตนด้วย ASP.Core

• MSDNs Introduction to Identity

บางคนนำเสนอโซลูชันที่ปรับเปลี่ยนได้โดยระบุว่าจะใช้โซลูชันบนคลาวด์เช่น Azure AD หรือใช้ IdentityServer4 และโฮสต์ Token Server ของฉันเอง

ในเวอร์ชันเก่ากว่าของ. Net หนึ่งในรูปแบบการพิสูจน์ตัวตนที่ง่ายกว่าคือการสร้าง Custom Iprinciple และเก็บข้อมูลผู้ใช้การพิสูจน์ตัวตนเพิ่มเติมไว้ภายใน

public interface ICustomPrincipal : System.Security.Principal.IPrincipal
{
    string FirstName { get; set; }

    string LastName { get; set; }
}

public class CustomPrincipal : ICustomPrincipal
{
    public IIdentity Identity { get; private set; }

    public CustomPrincipal(string username)
    {
        this.Identity = new GenericIdentity(username);
    }

    public bool IsInRole(string role)
    {
        return Identity != null && Identity.IsAuthenticated && 
           !string.IsNullOrWhiteSpace(role) && Roles.IsUserInRole(Identity.Name, role);
    }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public string FullName { get { return FirstName + " " + LastName; } }
}

public class CustomPrincipalSerializedModel
{
    public int Id { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }
}

จากนั้นคุณจะทำให้ข้อมูลของคุณเป็นอนุกรมเป็นคุกกี้และส่งกลับไปยังลูกค้า

public void CreateAuthenticationTicket(string username) {     

    var authUser = Repository.Find(u => u.Username == username);  
    CustomPrincipalSerializedModel serializeModel = new CustomPrincipalSerializedModel();

    serializeModel.FirstName = authUser.FirstName;
    serializeModel.LastName = authUser.LastName;
    JavaScriptSerializer serializer = new JavaScriptSerializer();
    string userData = serializer.Serialize(serializeModel);

    FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
    1,username,DateTime.Now,DateTime.Now.AddHours(8),false,userData);
    string encTicket = FormsAuthentication.Encrypt(authTicket);
    HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
    Response.Cookies.Add(faCookie);
}

คำถามของฉันคือ:

1. ฉันจะตรวจสอบความถูกต้องคล้ายกับวิธีที่ทำใน. Net เวอร์ชันก่อนหน้าได้อย่างไรวิธีเก่ายังใช้งานได้หรือมีเวอร์ชันที่ใหม่กว่า

2. ข้อดีข้อเสียของการใช้ข้อตกลงเซิร์ฟเวอร์โทเค็นของคุณเองที่สร้างหลักการของคุณเองคืออะไร?

3. เมื่อใช้โซลูชันบนคลาวด์หรือเซิร์ฟเวอร์โทเค็นแยกต่างหากคุณจะรวมเข้ากับแอปพลิเคชันปัจจุบันของคุณได้อย่างไรฉันจะยังต้องการตารางผู้ใช้ในแอปพลิเคชันของฉันคุณจะเชื่อมโยงทั้งสองได้อย่างไร

4. เนื่องจากมีโซลูชันที่แตกต่างกันมากมายฉันจะสร้างแอปพลิเคชันสำหรับองค์กรได้อย่างไรเพื่ออนุญาตให้เข้าสู่ระบบผ่าน Gmail / Facebook ในขณะที่ยังสามารถขยายไปยัง SSO อื่น ๆ ได้

5. การนำเทคโนโลยีเหล่านี้ไปใช้งานง่ายๆมีอะไรบ้าง?

TL; ดร

IdentityServer = บริการเข้ารหัสโทเค็นและตรวจสอบความถูกต้องผ่าน OAuth 2.0 / OpenId-Connect

ASP.NET Identity = กลยุทธ์การจัดการข้อมูลประจำตัวปัจจุบันใน ASP.NET

ฉันจะตรวจสอบความถูกต้องคล้ายกับวิธีที่ทำใน. Net เวอร์ชันก่อนหน้าได้อย่างไรวิธีเก่ายังใช้งานได้หรือมีเวอร์ชันที่ใหม่กว่า

ฉันไม่เห็นเหตุผลว่าทำไมคุณถึงไม่สามารถบรรลุแนวทางเดิมใน ASP.NET Core ได้ แต่โดยทั่วไปแล้วกลยุทธ์นั้นถูกแทนที่ด้วย ASP.NET Identity และ ASP.NET Identity นั้นยังมีชีวิตอยู่และดีใน ASP.NET Core

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity

ASP.NET Identity ใช้ที่เก็บสำรองเช่น SQL Server เพื่อเก็บข้อมูลผู้ใช้เช่นชื่อผู้ใช้รหัสผ่าน (แฮช) อีเมลโทรศัพท์และสามารถขยายเพื่อเก็บ FirstName, LastName หรือสิ่งอื่น ๆ ได้อย่างง่ายดาย ดังนั้นจึงไม่มีเหตุผลที่จะเข้ารหัสข้อมูลผู้ใช้ลงในคุกกี้และส่งผ่านไปมาจากไคลเอนต์ไปยังเซิร์ฟเวอร์ สนับสนุนแนวคิดเช่นการอ้างสิทธิ์ของผู้ใช้โทเค็นผู้ใช้บทบาทของผู้ใช้และการเข้าสู่ระบบภายนอก นี่คือเอนทิตีใน ASP.NET Identity:

• AspNetUsers
• AspNetUserRoles
• AspNetUserClaims
• AspNetUserLogins (สำหรับการเชื่อมโยงผู้ให้บริการข้อมูลประจำตัวภายนอกเช่น Google, AAD)
• AspNetUserTokens (สำหรับเก็บสิ่งต่างๆเช่น access_tokens และ refresh_tokens ที่รวบรวมโดยผู้ใช้)

ข้อดีข้อเสียของการใช้ข้อตกลงเซิร์ฟเวอร์โทเค็นของคุณเองที่สร้างหลักการของคุณเองคืออะไร?

เซิร์ฟเวอร์โทเค็นจะเป็นระบบที่สร้างโครงสร้างข้อมูลง่ายๆที่มีข้อมูลการอนุญาตและ / หรือการพิสูจน์ตัวตน การอนุมัติมักจะใช้เวลาสำหรับของชื่อโทเค็นACCESS_TOKEN นี่จะเป็น "กุญแจสู่บ้าน" ดังนั้นหากต้องการพูดให้คุณเดินผ่านประตูบ้านและเข้าไปในที่อยู่อาศัยของทรัพยากรที่ได้รับการคุ้มครองโดยปกติจะเป็นเว็บ API สำหรับการพิสูจน์ตัวตนจะid_tokenมีตัวระบุเฉพาะสำหรับผู้ใช้ / บุคคล ในขณะที่มันเป็นเรื่องธรรมดาที่จะนำตัวบ่งชี้ดังกล่าวใน ACCESS_TOKEN ที่มีอยู่ในขณะนี้โปรโตคอลเฉพาะสำหรับการทำที่: OpenID-Connect

เหตุผลที่ต้องมี Security Token Service (STS) ของคุณเองคือเพื่อปกป้องทรัพย์สินข้อมูลของคุณผ่านการเข้ารหัสและควบคุมว่าไคลเอนต์ (แอปพลิเคชัน) ใดที่สามารถเข้าถึงทรัพยากรเหล่านั้นได้ นอกจากนี้มาตรฐานสำหรับการควบคุมข้อมูลประจำตัวยังมีอยู่ในข้อกำหนดของ OpenID-Connect IdentityServer เป็นตัวอย่างของ OAuth 2.0 Authorization Server ที่รวมกับเซิร์ฟเวอร์ OpenID-Connect Authentication

แต่สิ่งนี้ไม่จำเป็นหากคุณต้องการเพียงแค่ตารางผู้ใช้ในแอปพลิเคชันของคุณ คุณไม่จำเป็นต้องมีเซิร์ฟเวอร์โทเค็นเพียงแค่ใช้ ASP.NET Identity ASP.NET Identity จับคู่ผู้ใช้ของคุณกับอ็อบเจ็กต์ClaimsIdentityบนเซิร์ฟเวอร์ - ไม่จำเป็นต้องมีคลาส IPrincipal ที่กำหนดเอง

เมื่อใช้โซลูชันบนคลาวด์หรือเซิร์ฟเวอร์โทเค็นแยกต่างหากคุณจะรวมเข้ากับแอปพลิเคชันปัจจุบันของคุณได้อย่างไรฉันจะยังต้องการตารางผู้ใช้ในแอปพลิเคชันของฉันคุณจะเชื่อมโยงทั้งสองได้อย่างไร

ดูบทช่วยสอนเหล่านี้สำหรับการผสานรวมโซลูชันข้อมูลประจำตัวแยกกับแอปพลิเคชัน: https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html https://auth0.com/docs/quickstart/webapp/aspnet-core

อย่างน้อยที่สุดคุณจะต้องมีตารางสองคอลัมน์ที่แมปชื่อผู้ใช้กับตัวระบุผู้ใช้ของผู้ให้บริการภายนอก นี่คือสิ่งที่ตาราง AspNetUserLogins ทำใน ASP.NET Identity อย่างไรก็ตามแถวในตารางนั้นขึ้นอยู่กับการเป็นระเบียนผู้ใช้ใน AspNetUsers

ASP.NET Identity รองรับผู้ให้บริการภายนอกเช่น Google, Microsoft, Facebook, ผู้ให้บริการ OpenID-Connect, Azure AD มีอยู่แล้ว (Google และ Microsoft ได้ติดตั้งโปรโตคอล OpenID-Connect แล้วดังนั้นคุณจึงไม่จำเป็นต้องใช้แพ็คเกจการรวมที่กำหนดเองเช่นนี้ ) นอกจากนี้ ADFS ยังไม่พร้อมใช้งานบน ASP.NET Core Identity

ดูเอกสารนี้เพื่อเริ่มต้นกับผู้ให้บริการภายนอกใน ASP.NET Identity:

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/

เนื่องจากมีโซลูชันที่แตกต่างกันมากมายฉันจะสร้างแอปพลิเคชันสำหรับองค์กรได้อย่างไรเพื่ออนุญาตให้เข้าสู่ระบบผ่าน Gmail / Facebook ในขณะที่ยังสามารถขยายไปยัง SSO อื่น ๆ ได้

ตามที่อธิบายไว้ข้างต้น ASP.NET Identity ทำสิ่งนี้อยู่แล้ว การสร้างตาราง "ผู้ให้บริการภายนอก" ค่อนข้างง่ายและข้อมูลจะขับเคลื่อนกระบวนการเข้าสู่ระบบภายนอกของคุณ ดังนั้นเมื่อมี "SSO" ใหม่ให้เพิ่มแถวใหม่ที่มีคุณสมบัติเช่น url ของผู้ให้บริการรหัสไคลเอ็นต์และข้อมูลลับที่ให้คุณ ASP.NET Identity มี UI อยู่แล้วในเทมเพลต Visual Studio แต่โปรดดูที่ปุ่มเข้าสู่ระบบทางสังคมสำหรับปุ่มที่เย็น

สรุป

หากคุณต้องการเพียงแค่ตารางผู้ใช้ที่มีความสามารถในการลงชื่อเข้าใช้ด้วยรหัสผ่านและโปรไฟล์ผู้ใช้ ASP.NET Identity ก็สมบูรณ์แบบ ไม่จำเป็นต้องเกี่ยวข้องกับหน่วยงานภายนอก แต่หากมีแอปพลิเคชันจำนวนมากที่ต้องการเข้าถึง apis จำนวนมากผู้มีอำนาจอิสระในการรักษาความปลอดภัยและตรวจสอบข้อมูลประจำตัวและการเข้าถึงโทเค็นก็สมเหตุสมผล IdentityServer เหมาะหรือดูopeniddict-coreหรือAuth0สำหรับโซลูชันระบบคลาวด์

คำขอโทษของฉันคือสิ่งนี้ไม่ได้กดปุ่มเครื่องหมายหรือเป็นการเกริ่นเกินไป โปรดอย่าลังเลที่จะโต้ตอบเพื่อไปยังวัวตาเดียวที่คุณกำลังมองหา

ภาคผนวก: การตรวจสอบสิทธิ์คุกกี้

หากต้องการตรวจสอบสิทธิ์แบบเปลือยด้วยคุกกี้ให้ทำตามขั้นตอนเหล่านี้ แต่สำหรับความรู้ของฉันไม่สนับสนุนหลักการเรียกร้องที่กำหนดเอง เพื่อให้ได้ผลเช่นเดียวกันใช้รายการการอ้างสิทธิ์ของClaimPrincipalวัตถุ

สร้างเว็บแอปพลิเคชัน ASP.NET Core 1.1 ใหม่ใน Visual Studio 2015/2017 โดยเลือก "No Authentication" ในกล่องโต้ตอบ จากนั้นเพิ่มแพ็คเกจ:

Microsoft.AspNetCore.Authentication.Cookies

ภายใต้ConfigureวิธีการStartup.csนี้ (ก่อนหน้าapp.UseMvc):

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationScheme = "MyCookieMiddlewareInstance",
    LoginPath = new PathString("/Controller/Login/"),
    AutomaticAuthenticate = true,
    AutomaticChallenge = true
});

จากนั้นสร้าง UI สำหรับเข้าสู่ระบบและโพสต์ฟอร์ม html ไปยัง Action Method ดังนี้:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(String username, String password, String returnUrl = null)
{
    ViewData["ReturnUrl"] = returnUrl;
    if (ModelState.IsValid)
    {
        // check user's password hash in database
        // retrieve user info

        var claims = new List<Claim>
        {
            new Claim(ClaimTypes.Name, username),
            new Claim("FirstName", "Alice"),
            new Claim("LastName", "Smith")
        };

        var identity = new ClaimsIdentity(claims, "Password");

        var principal = new ClaimsPrincipal(identity);

        await HttpContext.Authentication.SignInAsync("MyCookieMiddlewareInstance", principal);

        return RedirectToLocal(returnUrl);
    }

    ModelState.AddModelError(String.Empty, "Invalid login attempt.");

    return View();
}

อ็อบเจ็กต์ HttpContext.User ควรมีการอ้างสิทธิ์ที่กำหนดเองของคุณและสามารถเรียกคืนคอลเล็กชัน List ของ ClaimPrincipal ได้อย่างง่ายดาย

ฉันหวังว่าสิ่งนี้จะเพียงพอเนื่องจากโซลูชัน / โครงการเต็มรูปแบบดูเหมือนจะค่อนข้างมากสำหรับโพสต์ StackOverflow

TL; ดร

ฉันอยากจะแสดงการโพสต์แบบเต็มเกี่ยวกับวิธีใช้ IdentityServer4 อย่างถูกต้อง แต่ฉันพยายามทำให้พอดีกับข้อความทั้งหมด แต่มันเกินขีด จำกัด ของสิ่งที่ StackOverflow ยอมรับดังนั้นฉันจะแก้ไขเคล็ดลับและสิ่งที่ฉันได้เรียนรู้แทน

ประโยชน์ของการใช้ Token Server Vs ASP Identity คืออะไร?

เซิร์ฟเวอร์โทเค็นมีประโยชน์มากมาย แต่ไม่เหมาะสำหรับทุกคน หากคุณกำลังใช้งานองค์กรเช่นโซลูชันที่คุณต้องการให้ไคลเอนต์หลายคนสามารถเข้าสู่ระบบได้เซิร์ฟเวอร์โทเค็นเป็นทางออกที่ดีที่สุดของคุณ แต่ถ้าคุณเพียงแค่สร้างเว็บไซต์ง่ายๆที่ต้องการรองรับการเข้าสู่ระบบภายนอกคุณสามารถหลีกเลี่ยงได้ด้วย ASP Identity และ มิดเดิลแวร์บางตัว

Identity Server 4 คำแนะนำ

Identity server 4 ได้รับการบันทึกไว้ค่อนข้างดีเมื่อเทียบกับเฟรมเวิร์กอื่น ๆ ที่ฉันเคยเห็น แต่มันยากที่จะเริ่มตั้งแต่ต้นและดูภาพรวมทั้งหมด

ความผิดพลาดครั้งแรกของฉันพยายามใช้ OAuth เป็นการตรวจสอบสิทธิ์ใช่มีหลายวิธีในการดำเนินการดังกล่าว แต่ OAuth มีไว้สำหรับการอนุญาตไม่ใช่การตรวจสอบสิทธิ์หากคุณต้องการตรวจสอบสิทธิ์ให้ใช้ OpenIdConnect (OIDC)

ในกรณีของฉันฉันต้องการสร้างไคลเอนต์ javascript ซึ่งเชื่อมต่อกับเว็บ API ฉันดูวิธีแก้ปัญหามากมาย แต่ในตอนแรกฉันพยายามใช้ webapi เพื่อเรียกการพิสูจน์ตัวตนกับเซิร์ฟเวอร์ Identity และจะมีโทเค็นนั้นคงอยู่เนื่องจากได้รับการตรวจสอบกับเซิร์ฟเวอร์แล้ว การไหลนั้นอาจใช้งานได้ แต่มีข้อบกพร่องมากมาย

ในที่สุดโฟลว์ที่เหมาะสมเมื่อฉันพบตัวอย่างไคลเอ็นต์ Javascript ฉันได้โฟลว์ที่ถูกต้อง ลูกค้าของคุณเข้าสู่ระบบและตั้งค่าโทเค็น จากนั้นคุณมีเว็บ API ของคุณใช้ไคลเอนต์ OIdc ซึ่งจะตรวจสอบว่าคุณเข้าถึงโทเค็นกับ IdentityServer

การเชื่อมต่อกับร้านค้าและการย้ายข้อมูล ฉันมีความเข้าใจผิดหลายอย่างเกี่ยวกับการย้ายข้อมูลในตอนแรก ฉันรู้สึกประทับใจที่เรียกใช้การย้ายข้อมูลสร้าง SQL จาก dll ภายในแทนที่จะใช้บริบทที่คุณกำหนดค่าไว้เพื่อหาวิธีสร้าง SQL

มีไวยากรณ์สองแบบสำหรับการย้ายข้อมูลที่ทราบว่าคอมพิวเตอร์ของคุณใช้เป็นสิ่งสำคัญ:

dotnet ef migrations add InitialIdentityServerMigration -c ApplicationDbContext

Add-Migration InitialIdentityServerDbMigration -c ApplicationDbContext

ฉันคิดว่าพารามิเตอร์หลังการโอนย้ายคือชื่อทำไมคุณต้องใช้ชื่อฉันไม่แน่ใจApplicationDbContextคือ Code-First DbContext ที่คุณต้องการสร้าง

การย้ายข้อมูลใช้เวทมนตร์อัตโนมัติเพื่อค้นหาสตริงการเชื่อมต่อของคุณจากการกำหนดค่าการเริ่มต้นของคุณฉันเพิ่งสันนิษฐานว่าใช้การเชื่อมต่อจาก Server Explorer

หากคุณมีหลายโปรเจ็กต์ตรวจสอบให้แน่ใจว่าคุณมีโปรเจ็กต์ที่มี ApplicationDbContext ตั้งไว้เมื่อคุณเริ่มต้น

มีส่วนที่เคลื่อนไหวมากมายเมื่อใช้งานการอนุญาตและการรับรองความถูกต้องหวังว่าโพสต์นี้จะช่วยใครบางคนได้ วิธีที่ง่ายที่สุดในการทำความเข้าใจการรับรองความถูกต้องอย่างสมบูรณ์คือการเลือกตัวอย่างเพื่อรวมทุกอย่างเข้าด้วยกันและตรวจสอบให้แน่ใจว่าคุณอ่านเอกสาร

ASP.NET Identity - นี่คือโครงสร้างในการตรวจสอบความถูกต้องของแอปพลิเคชันของคุณไม่ว่าจะเป็น Bearer หรือ Basic Authentication โดยให้รหัสสำเร็จรูปแก่เราเพื่อทำการลงทะเบียนผู้ใช้เข้าสู่ระบบเปลี่ยนรหัสผ่านและทั้งหมด

ตอนนี้ถือว่าเรามี 10 แอปพลิเคชั่นที่แตกต่างกันและมันเป็นไปไม่ได้ที่จะทำสิ่งเดียวกันในทั้ง 10 แอพ การปฏิบัติที่เปราะบางและเลวร้ายมาก

ในการแก้ไขปัญหานี้สิ่งที่เราทำได้คือรวมการรับรองความถูกต้องและการอนุญาตของเราไว้ที่ส่วนกลางดังนั้นเมื่อใดก็ตามที่มีการเปลี่ยนแปลงนี้จะไม่ส่งผลกระทบต่อแอปทั้ง 10 แอปของเรา

เซิร์ฟเวอร์ข้อมูลประจำตัวให้ความสามารถในการทำเช่นเดียวกัน เราสามารถสร้างเว็บแอปตัวอย่างหนึ่งรายการที่ใช้เป็นบริการ Identity และจะตรวจสอบความถูกต้องของผู้ใช้ของคุณและให้โทเค็นการเข้าถึง JWT

ฉันใช้การอนุญาต / การรับรองความถูกต้องในตัว ASP.NET (และก่อนหน้านี้เป็นสมาชิก) อยู่เสมอฉันได้ติดตั้ง Auth0 เมื่อเร็ว ๆ นี้ ( https://auth0.com ) และแนะนำให้ลองทำเช่นนี้

การเข้าสู่ระบบโซเชียลไม่ใช่เรื่องยากที่จะนำไปใช้กับ Identity แต่มีการตั้งค่าเริ่มต้นบางอย่างที่เกี่ยวข้องและบางครั้งขั้นตอนที่คุณพบทางออนไลน์ในเอกสารนั้นไม่เหมือนกันโดยปกติแล้วคุณสามารถค้นหาความช่วยเหลือได้ภายใต้ส่วนนักพัฒนาของแพลตฟอร์มที่คุณกำลังพยายามตั้งค่า การเข้าสู่ระบบโซเชียลสำหรับ Identity คือการแทนที่ฟังก์ชันการเป็นสมาชิกแบบเก่าที่พบใน. net framework เวอร์ชันดั้งเดิมสิ่งที่ฉันพบว่าน่าแปลกใจก็คือกรณีการใช้งาน edge เช่นการส่งโทเค็น jwt ที่คุณมีอยู่แล้วไปยัง web api จะไม่ครอบคลุมทุกที่ในตัวอย่างออนไลน์ แม้ในเรื่องพหูพจน์ฉันแน่ใจว่าคุณไม่จำเป็นต้องมีสิทธิ์โทเค็นของคุณเองในการทำสิ่งนี้ แต่ฉันไม่พบตัวอย่างเดียวเกี่ยวกับวิธีการส่งข้อมูลในการรับหรือโพสต์ที่ไม่ได้เกี่ยวข้องกับเซิร์ฟเวอร์ที่โฮสต์เอง