VPN SSO có tự động đăng nhập người dùng vào các ứng dụng nội bộ không?

Một cổng VPN xác thực qua nhà cung cấp danh tính chỉ chứng minh một điều: nhà cung cấp đã bảo lãnh cho người dùng trước cổng. Nó không trao cho người dùng đó thông tin đăng nhập cho wiki mạng nội bộ, bảng điều khiển giám sát hay máy chủ build. Những dịch vụ đó đăng nhập người ta qua liên hợp của riêng chúng và áp dụng quyền hạn riêng, còn đường hầm chỉ quyết định gói nào có thể đến được chúng.

Ba phiên, ba quyết định riêng

Hãy tách biệt các trạng thái, vì mỗi trạng thái hết hạn theo lịch riêng của nó. Phiên VPN là việc cổng chấp nhận một danh tính cộng với quyền truy cập mạng mà nó đã cấp. Phiên trình duyệt ở nhà cung cấp danh tính là những gì trình duyệt còn giữ cho nhà cung cấp đó và có thể dùng lại theo chính sách của nó. Phiên ứng dụng thuộc về một dịch vụ đã xác thực một phản hồi gửi cho nó.

Nhầm lẫn các trạng thái đó tạo ra câu hỏi sai, thường được đặt là tại sao đường hầm không đăng nhập người dùng ở mọi nơi. Hãy diễn đạt lại: ứng dụng nào không có mục liên hợp, ứng dụng nào từ chối người dùng và ứng dụng nào thiếu tuyến đường. Một lời nhắc đăng nhập duy nhất mở ứng dụng mạng nội bộ vẫn có thể quay lại nhà cung cấp, vì lần chuyển hướng thứ hai là yêu cầu ủy quyền mới cho một đối tượng khác.

Kết nối cổng như một ứng dụng riêng

Đăng ký VPN làm ứng dụng được phê duyệt tại nhà cung cấp, với định danh, URI chuyển hướng và việc gán người dùng riêng. Sau đó quyết định lần đăng nhập đó cấp những ủy quyền mạng nào, vì đó là chính sách VPN chứ không phải tính năng của nhà cung cấp. Người dùng chỉ được đến mạng con giám sát nhận chính sách cổng khác, không phải mật khẩu khác.

Phản hồi xác thực của đường hầm không phải là thông tin đăng nhập dùng lại được. Token ID của OIDC mang theo yêu cầu đối tượng nêu tên máy khách mà chúng được cấp cho, và các khẳng định bearer của SAML giới hạn đối tượng trong nhà cung cấp dịch vụ nhận. Một dịch vụ thứ hai chấp nhận phản hồi của dịch vụ thứ nhất là cấu hình sai, và sao chép token sang ứng dụng khác không phải là tích hợp.

Đăng ký từng ứng dụng nội bộ, sau đó đặt ngữ cảnh trình duyệt

Mỗi dịch vụ cần các giá trị SAML hoặc OIDC được hỗ trợ: nhà phát hành, định danh máy khách, URL gọi lại hoặc nơi tiêu thụ khẳng định, các yêu cầu bắt buộc và việc gán. Khả năng tiếp cận đến ở trên đó, vì việc kiểm tra danh tính không bao giờ cung cấp tuyến đường hay câu trả lời DNS.

1. Tạo mục ứng dụng và xác nhận rằng ID thực thể hoặc máy khách khớp với những gì ứng dụng gửi.
2. Đăng ký URL gọi lại chính xác bao gồm lược đồ và cổng; một sai sót nhỏ sẽ thất bại sau khi người dùng xác thực.
3. Gán người dùng hoặc nhóm, sau đó xác nhận rằng các yêu cầu bắt buộc được phát ra.
4. Cho phép các điểm cuối của nhà cung cấp danh tính cùng với ứng dụng riêng tư, nếu không việc chuyển hướng không thể hoàn tất.

Ngữ cảnh trình duyệt quyết định liệu phiên nhà cung cấp hiện có có được dùng lại hay không. Một ứng dụng gốc mở trình duyệt hệ thống có thể chia sẻ trạng thái đó, trong khi chế độ xem nhúng với lọ cookie riêng thường không thể. Trình duyệt mới, cửa sổ riêng tư và hồ sơ thứ hai đều bắt đầu từ con số không, điều này là bình thường chứ không phải cấu hình SSO hỏng.

Chạy luồng và đọc xem nó dừng ở đâu

Tái hiện bằng bảng mạng của trình duyệt và theo dõi chuỗi chuyển hướng. Một lượt hữu ích đi từng bước một: từ cổng đến nhà cung cấp, từ nhà cung cấp trở lại ứng dụng với mã hoặc khẳng định, từ ứng dụng đến điểm cuối token của nhà cung cấp, phiên ứng dụng được phát ra. Bước mà chuỗi dừng lại chỉ ra thành phần cần sửa.

Hai kiểm tra dòng lệnh giải quyết những nghi ngờ thường gặp, và cả hai đều an toàn khi chạy từ máy chủ quản trị:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

Khi siêu dữ liệu liệt kê các điểm cuối bạn chưa từng đăng ký, ứng dụng đang trỏ đến một đối tượng thuê hoặc nhà phát hành khác. Khi yêu cầu đầu tiên đến ứng dụng trả lời 302 tới một máy chủ không mong đợi, nơi cần xem là cấu hình liên hợp của ứng dụng, không phải hồ sơ VPN.

Sửa lời nhắc bằng cách tìm ra ai đã yêu cầu

Lời nhắc mật khẩu thứ hai không tự động là lỗi. Ứng dụng có thể yêu cầu mức bảo đảm cao hơn, hoặc nhà cung cấp có thể áp đặt tuổi phiên tối đa và một thách thức mới. Việc loại bỏ những yêu cầu đó để luồng yên tĩnh hơn làm suy yếu một kiểm soát có chủ đích, nên hãy xác định thành phần nào đã yêu cầu trước khi thay đổi chính sách.

Sau đó quyết định cải thiện điều gì. Nếu lời nhắc đến từ ứng dụng, hãy sửa mục liên hợp của nó. Nếu đến từ nhà cung cấp theo chính sách, hãy ghi lại yêu cầu. Nếu không thể truy cập ứng dụng sau khi đăng nhập thành công, định tuyến của đường hầm là đối tượng tình nghi, vì danh tính và việc giao gói tin thất bại ở những nơi khác nhau và trông giống nhau từ chỗ ngồi của người dùng.