Chúng tôi đăng nhập vào bảng điều khiển admin của chính mình bằng SAML của chính mình. Đây là những gì nó bắt được.

Có một kiểu dogfooding chỉ là khẩu hiệu, và một kiểu mà chính nhân viên của bạn không thể đẩy code lên cho đến khi lỗi được sửa. Chúng tôi theo kiểu thứ hai. Bảng điều khiển nhân viên Authagonal, công cụ chúng tôi dùng để quản lý mọi tenant, xác thực thông qua chính Authagonal: SAML single sign-on từ thư mục Entra của chúng tôi, với SCIM quyết định ai được vào và họ được làm gì. Không có bảng mật khẩu admin riêng. Chúng tôi đã xóa nó. Nếu SAML của chính chúng tôi hỏng, chúng tôi bị khóa ngoài chính sản phẩm của mình.

Điều đó khó chịu theo đúng cái cách hữu ích. Nó biến "SSO là một tính năng enterprise mà chúng tôi hỗ trợ" thành "SSO là cách duy nhất để những người xây dựng nên nó có thể làm việc hôm nay." Đây là những gì việc trở thành khách hàng của chính mình đã bắt được.

Một bản build đã trimmed làm hỏng việc xác minh chữ ký

Chúng tôi phát hành auth server ở dạng trimmed, để giữ image nhỏ gọn. Trimming xóa quyết liệt phần code mà nó không thể chứng minh là được dùng, và reflection che giấu việc sử dụng đó khỏi nó. .NET phân giải các thuật toán mã hóa ký XML của mình theo tên, qua reflection, thông qua CryptoConfig. Trimmer không thể thấy rằng các kiểu đó cần thiết, đã xóa chúng đi, và SignedXml lặng lẽ trở nên không thể dựng được thuật toán. Việc xác minh chữ ký SAML, bước chứng minh rằng phiên đăng nhập là thật, đã ném ra một null reference lúc chạy.

Các unit test đều qua, vì chúng chạy trên bản build chưa trimmed nơi các kiểu vẫn còn tồn tại. Chỉ artefact production đã trimmed mới hỏng, và nó hỏng đúng vào khoảnh khắc một con người cố đăng nhập. Bây giờ chúng tôi phát hành auth server ở dạng chưa trimmed, với một sự ngờ vực lành mạnh đối với việc trim bất cứ thứ gì gần với phần mã hóa dựa trên reflection. Nếu chúng tôi chỉ hỗ trợ SAML thay vì sống nhờ nó, thì đây sẽ là báo cáo sự cố của một khách hàng chứ không phải của chúng tôi.

Provisioning mới chính là việc đăng nhập

Xác thực một người dùng là nửa dễ của SSO. Nửa khó là quyết định họ được phép làm gì và giữ cho điều đó đồng bộ khi người ta đến và đi. Chúng tôi điều khiển việc đó bằng SCIM: tư cách thành viên nhóm Entra được ánh xạ sang các vai trò, được phân giải ngay khoảnh khắc một token được phát hành, chứ không phải sao chép một lần lúc tạo tài khoản. Thêm ai đó vào đúng nhóm và họ có quyền truy cập ở lần đăng nhập kế tiếp; gỡ họ ra và quyền đó biến mất. Danh sách truy cập của chính chúng tôi dogfood đúng cái ánh xạ nhóm-sang-vai-trò mà chúng tôi cung cấp.

Cách đấu nối đó làm lộ ra một lớp lỗi chỉ tồn tại khi xác thực và phân quyền nằm ở hai hệ thống khác nhau: một admin vừa được provision có thể xác thực trước khi vai trò của họ kịp ổn định hoàn toàn, khiến lần đăng nhập đầu tiên ở trạng thái hợp lệ nhưng chưa được cấp quyền. Cách sửa nằm ở thứ tự của provisioning, không phải ở phần login, và bạn chỉ tìm ra nó bằng cách chính mình là admin mới đăng nhập lần đầu.

Một lỗi 500 lẽ ra phải là 403

Lỗi nhỏ nhất lại là lỗi đáng xấu hổ nhất. Khi một người dùng đã xác thực chạm vào thứ gì đó họ không được phép, API trả về 500 thay vì một 403 gọn gàng, vì nhánh code phát ra phản hồi "forbidden" phụ thuộc vào một dịch vụ không được đấu nối trong host đó. Một yêu cầu bị từ chối lẽ ra phải là một kết cục bình thản, được lường trước, không phải một lỗi server. Vô hình cho đến khi chính bạn là người bị từ chối.

Ranh giới chúng tôi quan tâm nhất

Bên dưới tất cả những điều đó là quy tắc duy nhất mà một nền tảng định danh multi-tenant không được phép làm sai: một tenant không bao giờ được trở thành admin của chúng tôi. Chúng tôi không tin vào một lần kiểm tra duy nhất. Nền tảng là issuer của chính nó và một tenant không thể đòi lấy slug của nó; khóa ký của nền tảng tách biệt với khóa của mọi tenant, nên một token được ký cho một tenant không thể bị tái sử dụng như một token nền tảng; và kho lưu trữ của nền tảng thực thi các vai trò nền tảng một cách độc lập. Ba lớp khóa, vì cái giá của việc một lớp hỏng theo hướng mở chính là toàn bộ sản phẩm.

Điểm mấu chốt

Không lỗi nào trong số này bị bắt bởi một test thông minh nào cả. Chúng bị bắt bởi một con người đang cố làm việc của mình mà không làm được. Đó là lý lẽ cho việc dùng chính sản phẩm của mình ở độ sâu mà nó có thể làm bạn đau: nó biến những lỗi ẩn nấp trong khe hở giữa các hệ thống thành những lỗi bạn sửa xong trước bữa sáng, vì bạn không thể phát hành cho đến khi sửa xong.

Mọi thứ mà bảng điều khiển của chúng tôi dựa vào (SSO, SAML, SCIM, MFA, nhật ký kiểm toán) đều có trong mọi gói Authagonal, không bị khóa sau một gói hay tính phí theo từng kết nối. Xem những gì được bao gồm.