2017-09-15 19 views
5

Luồng thông thường cho các ứng dụng chạy trong Azure và Dịch vụ ứng dụng là luồng thay mặt cho ứng dụng có thể trao đổi mã truy cập đến cùng với ClientId/ClientSecret để có quyền truy cập vào tài nguyên khác với tư cách người dùng. Nhìn vào tài liệu hiện tại, giới hạn, tài liệu trên API MSI, tôi chỉ thấy mã thông báo truy cập là chính ứng dụng.Hỗ trợ luồng thay mặt cho phù hợp với bản sắc dịch vụ được quản lý

Kịch bản OBO sẽ được hỗ trợ như thế nào/khi nào?

Tôi biết rằng bạn có thể lưu ClientId/ClientSecret trong Key Vault và sau đó sử dụng thẻ tín dụng MSI để truy xuất chúng, nhưng điều đó có vẻ dư thừa.

+0

Bạn có thấy tài liệu này https: //docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-on-behalf-of –

+0

Hi Wayne, Có, tôi biết lưu lượng, nhưng điều đó yêu cầu id ứng dụng khách và bí mật ứng dụng khách thực hiện. Câu hỏi liên quan đến việc nhận và quản lý chúng. Dường như không cần thiết, và không cần thiết, phải sử dụng Key Vault để lưu trữ những ứng dụng đó để ứng dụng có thể truy xuất chúng và sử dụng chúng khi điểm cuối mã thông báo MSI cũng có thể xử lý chúng. –

+0

@OrenNovotny IIUC, trong Bước 2, ClientId & Secret sẽ được truy xuất từ ​​MSI. – JoeBrockhaus

Trả lời

2

MSI không hỗ trợ Hành vi thay mặt cho luồng, hoặc khách hàng bí mật được ủy quyền khác OAuth 2.0 truyền với Azure AD (như luồng mã auth). Đó là trong quá trình thiết kế, chưa có ETA công bố.

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