Rời bỏ Duende tự lưu trữ: cái gì được di chuyển, và cái gì bạn thôi không phải vận hành

Duende IdentityServer là một phần mềm thực sự tốt: nếu bạn muốn tự sở hữu toàn bộ lớp định danh từ đầu đến cuối, nó là tiêu chuẩn trong .NET. Nhưng chính việc "sở hữu" đó mới là toàn bộ chi phí: bạn lưu trữ nó, vá nó, mở rộng nó và tự xây dựng mọi thứ xoay quanh nó, gồm giao diện quản trị, MFA, nhật ký kiểm toán, thương hiệu, trang trạng thái, quản lý người dùng và vai trò. Đến một lúc nào đó, một nhóm quyết định họ không muốn vận hành một IdP nữa, và câu hỏi duy nhất quan trọng là việc chuyển đổi đau đớn đến mức nào. Đây là những gì thực sự được di chuyển.

Bạn thực sự đang vận hành những gì

Tự lưu trữ Duende khiến bạn phải gánh nhiều thứ hơn là chỉ các endpoint token:

• Bản thân IdP: lưu trữ, mở rộng, vá lỗi và giấy phép (SAML là tiện ích bổ sung trả phí trên đó).
• Mọi thứ xoay quanh nó mà bạn tự xây dựng: cổng quản trị, đăng ký MFA, ghi nhật ký kiểm toán, thương hiệu tùy chỉnh, trang trạng thái, quản lý người dùng và vai trò.

Danh sách thứ hai đó thường là nơi ngốn nhiều thời gian thực sự.

Những gì được di chuyển, và phần lớn là máy móc

Duende lưu cấu hình của nó trong SQL (ConfigurationDb) và người dùng trong ASP.NET Identity. Một lần di chuyển sẽ đọc cả hai:

• Clients → các client OAuth, bao gồm URI chuyển hướng và đăng xuất, các nguồn CORS, các loại grant, ngữ nghĩa sử dụng/hết hạn của refresh token, và thời gian tồn tại của device code. Các client đã bị vô hiệu hóa được nhập ở trạng thái vô hiệu hóa; các secret đã hết hạn được bỏ qua kèm một cảnh báo.
• Scopes → ApiScopes và IdentityResources ánh xạ trực tiếp. Lớp trung gian ApiResource của Duende (một audience cộng với một danh sách claim dùng chung) được làm phẳng vào mô hình đơn giản hơn: tên tài nguyên trở thành một audience trên mọi client sử dụng một scope thành viên, và các claim của nó hợp nhất vào các scope đó.
• Users → tin tốt: các hash mật khẩu của ASP.NET Identity V3 (và bcrypt cũ) được xác minh nguyên bản và được băm lại trong lần đăng nhập đầu tiên. Không cần đặt lại mật khẩu, không có phiếu hỗ trợ, không có gì người dùng của bạn nhận ra. (Đây là phần thực sự khó khi rời Auth0: với Duende thì nó đơn giản là chạy được, vì đó chính là cùng một cách băm mà ứng dụng của bạn vốn đã dùng.)
• Vai trò và phân công, đăng nhập bên ngoài, và các nhà cung cấp định danh OIDC đều được chuyển sang. Các nhà cung cấp SAML được đánh dấu để bạn cấu hình lại ở phía bên kia.

Phần về sự ổn định của định danh

Như với bất kỳ lần chuyển IdP nào, điều cần làm đúng là không thay đổi sub của người dùng hoặc client_id: các refresh token ở hạ nguồn, các hàng SCIM trong IdP của khách hàng, và các ID người dùng được lưu trong cơ sở dữ liệu của chính bạn đều tham chiếu đến chúng. Trình nhập giữ nguyên cả hai. Và nếu một trong các chủ sở hữu cổng của bạn cũng tồn tại như một người dùng Duende dưới một ID khác, nó sẽ đối chiếu chúng (xoay sang sub của Duende) qua các bước theo trình tự, có thể khôi phục, thay vì để lại một chủ sở hữu bị di chuyển dở dang không thể đăng nhập.

Một lưu ý phụ về việc kiểm thử các lần di chuyển (một cái bẫy của .NET)

Chúng tôi kiểm thử trình nhập với một cơ sở dữ liệu Duende thật, đã được nạp dữ liệu, chứ không phải mock, và điều đó đã có ích. ASP.NET Identity lưu AspNetUsers.LockoutEnd dưới dạng datetimeoffset, và việc đọc nó bằng reader.GetDateTime() ném ra một InvalidCastException với kiểu đó. Vì vậy chỉ một người dùng bị khóa thôi cũng sẽ khiến toàn bộ quá trình nhập người dùng thất bại. Bạn chỉ phát hiện ra điều đó bằng cách chạy trình nhập với dữ liệu thật có chứa một người dùng bị khóa. Nếu bạn đang cân nhắc bất kỳ công cụ di chuyển nào, đó là câu hỏi đáng hỏi: nó được kiểm thử với một cơ sở dữ liệu đã nạp dữ liệu, hay chỉ được mock với API nguồn?

Những gì bạn thôi không phải làm nữa

Mục đích của việc chuyển đổi không phải là bản thân lần di chuyển: mà là mọi thứ sau đó. SAML, SCIM, MFA, nhật ký kiểm toán, tên miền tùy chỉnh và thương hiệu đều được bao gồm thay vì là những thứ bạn phải xây dựng và vận hành, và việc vá lỗi cùng mở rộng IdP thôi không còn là vấn đề của bạn nữa. Nếu việc tự lưu trữ Duende là một quyết định có chủ đích ("chúng tôi muốn toàn quyền kiểm soát") và vẫn còn đúng, thì hãy ở lại: đó là một lựa chọn hoàn toàn hợp lý. Bài này dành cho khi việc vận hành một IdP không còn là nơi bạn muốn dành thời gian của mình.

Nếu bạn đang cân nhắc

Lần di chuyển phần lớn là máy móc, mật khẩu được chuyển sang mà không cần đặt lại, và bản xem trước chỉ ở chế độ đọc: hãy trỏ nó vào cơ sở dữ liệu Duende của bạn và nó cho bạn thấy chính xác những gì sẽ được nhập trước khi bất cứ thứ gì được ghi.

→ Di chuyển khỏi Duende