Share via

Implementace komunikace mezi tenanty pomocí víceklientských aplikací

  • Článek

Tato příručka poskytuje řešení pro obousměrnou zabezpečenou komunikaci mezi službami hostovanými v předplatných Azure, které spravují různí tenanti Microsoft Entra.

Zabezpečení víceklientských komunikací v Azure může být náročné kvůli omezením, která jsou nedílnou součástí mnoha služeb. Pokud chcete získat tokeny z ID Microsoft Entra, můžete eliminovat potřebu správy přihlašovacích údajů přímo pomocí spravovaných identit Azure. Spravované identity Azure ale nefungují přes hranice tenanta a typickou alternativou je použití sdílených tajných kódů, jako jsou adresy URL sdíleného přístupového podpisu. Mějte na paměti, že pokud používáte sdílené tajné kódy, potřebujete bezpečně distribuovat a otáčet tajné kódy napříč hranicemi tenanta Microsoft Entra.

Jednou zmožnostích Prostřednictvím procesu vyjádření souhlasu můžete tuto identitu úlohy zpřístupnit externímu tenantovi a nakonec ji povolit ověřování služeb v externím tenantovi.

Tento článek představuje ukázkovou implementaci tohoto vzoru, který používá vzorový kód.

Tento model je možné znovu použít pro jakýkoli scénář s více tenanty, který má různé služby, které potřebují komunikovat přes hranice tenanta Microsoft Entra.

Architektura

Diagram architektury komunikace mezi tenanty

Stáhněte si soubor PowerPointu této architektury.

Workflow

Následující pracovní postup odpovídá předchozímu diagramu:

  1. Správce na straně poskytovatele vytvoří registraci víceklientské aplikace a nastaví pro něj tajný klíč klienta.

  2. Správce na straně zákazníka zřídí instanční objekt ve svém tenantovi. Tento instanční objekt je založen na víceklientských aplikacích, které poskytovatel vytvořil. Tento krok můžete provést několika způsoby. V tomto příkladu jsme se rozhodli vytvořit adresu URL, která se má poskytnout správci tenanta zákazníka, ale místo toho můžete použít rozhraní Microsoft Graph API.

  3. Zákazník na tento nový instanční objekt použije role řízení přístupu na základě role (RBAC), aby byl autorizovaný pro přístup ke službě Azure Service Bus.

  4. Aplikace funkcí poskytovatele používá ID klienta a tajný klíč klienta registrace aplikace k odeslání ověřené zprávy do fronty service bus zákazníka.

  5. Aplikace funkcí zákazníka používá spravovanou identitu ke čtení zprávy poskytovatele z fronty prostřednictvím triggeru služby Service Bus.

  6. Jakmile zprávu obdrží, aplikace funkcí zákazníka obvykle funguje před odesláním stavové zprávy zpět poskytovateli. V takovém případě aplikace funkcí okamžitě odešle stavovou zprávu poskytovateli v samostatné frontě ve stejné službě Service Bus.

  7. Tato aplikace funkcí čte ze stavové fronty z tenanta zákazníka prostřednictvím časovače, který azure Functions aktivuje.

Podrobnosti scénáře

Poskytovatel má více zákazníků. Poskytovatel a každý zákazník mají vlastního samostatného tenanta Microsoft Entra ID a prostředky Azure. Poskytovatel a každý zákazník potřebují zabezpečenou obousměrnou metodu komunikace, aby mohli vyměňovat zprávy prostřednictvím front Service Bus. Řešení by mělo mít poutavý příběh identity, který zabraňuje zavedení nepotřebných přihlašovacích údajů nebo tajných kódů.

Co vědět o víceklientských aplikacích

  • Objekt aplikace je globálně jedinečná instance aplikace.

  • Když je aplikace zaregistrovaná v Microsoft Entra, objekt aplikace a instanční objekt se automaticky vytvoří v tenantovi.

  • Instanční objekt se vytvoří v každém tenantovi, který používá aplikaci a odkazuje na objekt aplikace. Objekt aplikace má relaci 1:N s odpovídajícím instančním objektem.

  • Objekt aplikace je globální reprezentace vaší aplikace a používá se ve všech tenantech. Instanční objekt je místní reprezentace, která se používá v konkrétním tenantovi.

  • Instanční objekt musí být vytvořen v každém tenantovi, kde se aplikace používá, aby mohl vytvořit identitu pro přístup k prostředkům, které tenant zabezpečuje. Aplikace s jedním tenantem má ve svém domovském tenantovi pouze jeden objekt instančního objektu. Tento objekt instančního objektu je vytvořen a povolen pro použití během registrace aplikace. Víceklientská aplikace má také instanční objekt vytvořený v každém tenantovi a uživatel z daného tenanta souhlasil s jeho použitím.

  • Pokud chcete získat přístup k prostředkům zabezpečeným tenantem Microsoft Entra, musí objekt zabezpečení představovat entitu, která vyžaduje přístup.

  • Když je aplikaci uděleno oprávnění pro přístup k prostředkům v tenantovi při registraci nebo souhlasu, vytvoří se objekt instančního objektu. Tato architektura se implementuje s tokem souhlasu.

Jak poskytovatel zobrazí zprávu zákazníkovi?

V ideálním případě může poskytovatel přiřadit spravovanou identitu výpočetnímu prostředku Azure, který zodpovídá za odesílání zpráv do fronty zákazníka. Tenant zákazníka je nakonfigurovaný tak, aby důvěřoval spravovaným identitám z tenanta poskytovatele. Skutečná federace mezi dvěma tenanty Microsoft Entra, která by v podstatě umožňovala "sdílení" identit z jednoho tenanta do druhého, není v současné době možná. Poskytovatel se tedy musí ověřit pomocí identity, kterou zákazník rozpozná. Poskytovatel se musí ověřit v tenantovi Microsoft Entra zákazníka jako instanční objekt, o kterého zákazník ví.

Doporučujeme, aby poskytovatel zaregistroval víceklientní aplikaci ve svém vlastním tenantovi a pak každému zákazníkovi zřídil přidružený instanční objekt do svého tenanta. Poskytovatel se pak může ověřit v tenantovi zákazníka a rozhraníCH API hostovaných zákazníkem pomocí tohoto instančního objektu. Poskytovatel v tomto přístupu nikdy nemusí sdílet tajný klíč klienta. Správa přihlašovacích údajů je výhradní odpovědností poskytovatele.

Jak poskytovatel zobrazí zprávu zákazníka?

Doporučujeme zákazníkovi vytvořit nebo hostovat frontu, ze které může poskytovatel číst. Zákazník zapíše zprávu do fronty. Poskytovatel opakovaně dotazuje každou frontu zákazníka na zprávy pomocí instančního objektu. Nevýhodou tohoto přístupu je, že představuje latenci dotazování, když poskytovatel obdrží zprávu. Kód také musí běžet častěji ve zprostředkovateli, protože se musí probudit a provádět logiku dotazování místo čekání na aktivaci události. Správa přihlašovacích údajů však zůstává výhradní odpovědností poskytovatele, který podporuje zabezpečení.

Dalším možným řešením je vytvořit nebo hostovat frontu poskytovatele pro každého zákazníka. Každý zákazník vytvoří vlastní víceklientovou aplikaci a požádá ho, aby ho poskytovatel zřídil ve svém tenantovi jako objekt instančního objektu. Zákazník pak pomocí tohoto objektu instančního objektu odešle zprávy do fronty specifické pro zákazníka na straně poskytovatele. Správa přihlašovacích údajů zůstává výhradní odpovědností zákazníka. Nevýhodou tohoto přístupu je, že poskytovatel musí zřídit instanční objekty přidružené k zákaznickým aplikacím do svého tenanta. Tento proces je ruční a poskytovatelé pravděpodobně nechtějí, aby ruční kroky byly součástí toku pro onboarding nového zákazníka.

Nastavení ukázkového kódu

Následující kroky vás provedou procesem nastavení komunikace mezi tenanty mezi poskytovatelem a zákazníkem.

Nastavení zprostředkovatele

Nastavení poskytovatele zahrnuje kroky pro vygenerování a zřízení instančního objektu víceklientských aplikací a kroků pro zřízení tenanta zákazníka.

  1. Vytvořte aplikaci funkcí aktivovanou protokolem HTTP, která odešle zprávu pro zápis do fronty příkazů Service Bus zákazníka v rámci tenanta zákazníka.

  2. Vytvořte aplikaci funkcí aktivovanou časem, která bude pravidelně kontrolovat stavovou frontu v rámci služby Service Bus zákazníka v rámci tenanta zákazníka.

Vytvoření víceklientské aplikace v rámci tenanta poskytovatele

Nejprve vytvořte víceklientskou aplikaci v tenantovi poskytovatele a zřiďte ji v rámci tenanta zákazníka. V tomto scénáři je identita instančním objektem. Architektura dříve v tomto článku ukazuje, jak nastavit a zřídit instanční objekt z tenanta poskytovatele do tenanta zákazníka. Tato architektura také popisuje, jak zřídit více tenantů Microsoft Entra.

  1. Zvolte možnost víceklientských organizací.

  2. Přidejte následující web jako identifikátor URI přesměrování: https://entra.microsoft.com. Tento identifikátor URI můžete změnit tak, aby vyhovoval vašim obchodním potřebám.

  3. Zaregistrujte a poznamenejte si hodnotu ID aplikace (klienta).

Vytvoření nového tajného klíče klienta

  1. Po vytvoření víceklientská aplikace vytvořte tajný klíč klienta pro tento instanční objekt.

  2. Uložte vygenerovaný tajný kód do bezpečného umístění. Tajný klíč a ID klienta jsou vaše přihlašovací údaje klienta, které jsou potřeba k výměně kódu, v toku autorizačního kódu a tokenu ID v dalším kroku.

Azure Functions – aktivované protokolem HTTP

Pomocí funkce HTTP spusťte nasazení z tenanta poskytovatele odesláním zprávy do fronty nasazení service bus zákazníka. Jako metodu doručení jsme zvolili funkci aktivovanou protokolem HTTP, abychom mohli začít s testováním konceptu. Instanční objekt, který jste vygenerovali dříve, funguje jako přihlašovací údaje pro přístup k tenantovi zákazníka a zápis do konkrétní fronty v rámci služby Service Bus. Musíte také dokončit nastavení zákazníka, aby tento krok fungoval správně.

Azure Functions – Aktivované časovačem

Pomocí funkce aktivované časovačem můžete dotazovat frontu stavu nasazení z tenanta zákazníka. Frontu stavu nasazení každých 10 sekund se dotazujeme na ukázkové účely v tomto testování konceptu. Tento přístup eliminuje potřebu zákazníka, aby měl instanční objekt pro přístup k tenantovi poskytovatele.

Nastavení zákazníka

  1. Zřiďte instanční objekt úpravou a použitím poskytnuté adresy URL.

  2. Obor instančního objektu poskytovatele tak, aby používal příslušné ovládací prvky RBAC.

  3. Vytvořte funkci aktivovanou službou Service Bus, která přečte zprávu z fronty zpráv služby Service Bus a vloží zprávu do jiné fronty. Pro ukázkové účely je tento tok optimální pro testování funkčnosti.

  4. Vytvořte spravovanou identitu přiřazenou systémem pro funkci aktivovanou službou Service Bus.

  5. Přiřaďte obor spravované identity přiřazené systémem služby Service Bus.

Zřízení instančního objektu z tenanta poskytovatele pro tenanta zákazníka

  1. Po nahrazení parametru client_id řetězce dotazu vlastním ID klienta navštivte následující adresu URL: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    Instanční objekt můžete zřídit také do jiného tenanta Microsoft Entra pomocí volání rozhraní Microsoft Graph API pro správce, příkazu Azure PowerShellu nebo příkazu Azure CLI.

  2. Přihlaste se pomocí účtu z tenanta zákazníka.

  3. Na obrazovce souhlasu vyberte Přijmout , aby se aplikace poskytovatele zřídila v tenantovi zákazníka. Adresa URL se nakonec přesměruje na microsoft.comadresu , která má stále požadovaný vliv na zřízení identity do tenanta zákazníka.

  4. Ověřte identitu v rámci tenanta Microsoft Entra zákazníka tak, že přejdete do podnikových aplikací a zobrazí se nově zřízený instanční objekt.

Nastavení RBAC pro zřízený instanční objekt

Nastavte obor instančního objektu poskytovatele z nastavení instančního objektu poskytovatele tak, aby měl ve službě Service Bus roli Vlastník dat služby Service Bus. Tento instanční objekt se používá jak při zápisu do fronty s funkcí aktivovanou protokolem HTTP, tak čtení z fronty z funkce aktivované časovačem. Ujistěte se, že do instančního objektu přidáte roli Vlastník dat služby Azure Service Bus.

Azure Functions – Trigger služby Service Bus

Postupujte podle kroků v kurzu funkcí založených na identitách a definujte trigger funkce z fronty služby Service Bus a zjistěte, jak nastavit spravovanou identitu. Tyto pokyny vám pomůžou aktivovat aplikaci funkcí z fronty Service Bus při přidání zprávy do fronty. Spravovanou identitu také použijete při umístění zprávy do jiné fronty. Pro ukázkové účely používáme stejnou funkci k nasdílení zprávy.

V nově vytvořeném oboru názvů služby Service Bus vyberte Řízení přístupu (IAM). Můžete zobrazit a nakonfigurovat, kdo má přístup k prostředku v řídicí rovině.

Udělení přístupu aplikace funkcí k oboru názvů služby Service Bus pomocí spravovaných identit

  1. Ujistěte se, že do spravované identity přidáte roli Příjemce dat služby Azure Service Bus.

  2. V selektoru spravovaných identit zvolte Function App z kategorie spravovaná identita přiřazená systémem. Aplikace funkcí label může mít vedle sebe číslo v závorkách. Toto číslo označuje, kolik aplikací má identit přiřazených systémem v předplatném.

Připojení do služby Service Bus v aplikaci funkcí

  1. Na portálu vyhledejte aplikaci funkcí nebo ji přejděte na stránce Aplikace funkcí.

  2. V nastavení aplikace vyberte + Nový a vytvořte nové nastavení aplikace v tabulce. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Správa životního cyklu tajných klíčů klienta instančního objektu

Pokud do architektury mezi tenanty představíte tajné kódy, budete muset spravovat životní cyklus vygenerovaných tajných kódů klienta. Informace o bezpečném ukládání, obměně a monitorování tajných kódů klientů najdete v osvědčených postupech pro správu tajných kódů.

Místní nastavení

Každý podadresář obsahuje překryvnou verzi local.settings.json souborů, kterou je možné upravit tak, aby se funkce Azure spouštěly místně. Pokud chcete nakonfigurovat nastavení v Azure, aktualizujte Nastavení aplikace.

Příkaz DefaultAzureCredential před dosažením přihlašovacích údajů Azure CLI vyčíslí několik nastavení. Abyste se vyhnuli nejasnostem, doporučujeme spustit az login -t <tenant ID> příkaz, který při vývoji místních funkcí udělí správné přihlašovací údaje.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

  • Audrey Long | Vedoucí bezpečnostní softwarový inženýr
  • Mickey | Hlavní softwarový inženýr
  • John Garland | Hlavní softwarový inženýr

Další kroky