2017-09-15 55 views
5

Bardzo częstym przepływem dla aplikacji działających w usłudze Azure i usługach aplikacyjnych jest przepływ w imieniu, w którym aplikacja może wymieniać token dostępu przychodzącego wraz z jego ClientId/ClientSecret aby uzyskać dostęp do innego zasobu jako użytkownik. Patrząc na bieżące, ograniczone dokumenty w interfejsie API MSI, widzę tylko token dostępu jako samą aplikację.Obsługa przepływów bieżących za pomocą zarządzanych tożsamości usług

Jak/kiedy scenariusz OBO będzie wspierany?

Jestem świadomy, że można przechowywać ClientId/ClientSecret w skarbcu kluczy, a następnie użyć tych samych uprawnień MSI, aby odzyskać te, ale wydaje się to zbędne.

+0

Widziałeś ten dokument https: //docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-on-behalf-of –

+0

Hi Wayne, Tak, jestem świadomy przepływu, ale to wymaga identyfikatora klienta i tajnego klienta aplikacji do wykonania. Pytanie dotyczy uzyskania i zarządzania nimi. Wydaje się zbędne i niepotrzebne, aby korzystać z Magazynu kluczy tylko po to, aby je przechowywać, aby aplikacja mogła je odzyskać i używać ich, gdy punkt końcowy tokena MSI poradzi sobie z nimi. –

+0

@OrenNovotny IIUC, podczas kroku 2, ClientId & Secret zostałby pobrany z MSI. – JoeBrockhaus

Odpowiedz

2

MSI nie obsługuje jeszcze przepływu W imieniu użytkownika lub innego delegowanego klienta poufnego OAuth 2.0 przepływa z usługą Azure AD (na przykład przepływ kodu uwierzytelniającego). Jest w procesie projektowania, nie ogłoszono jeszcze ETA.