Typy tożsamości i kont dla aplikacji jednodostępnych i wielodostępnych
W tym artykule wyjaśniono, w jaki sposób jako deweloper możesz wybrać, czy aplikacja zezwala tylko użytkownikom z dzierżawy microsoft Entra, dowolnej dzierżawy microsoft Entra lub użytkowników z osobistymi kontami Microsoft. Aplikację można skonfigurować tak, aby mogła być pojedyncza dzierżawa lub wielodostępna podczas rejestracji aplikacji w usłudze Microsoft Entra. Upewnij się, że zasada zerowego zaufania dostępu do najniższych uprawnień, aby aplikacja żądała tylko wymaganych uprawnień.
Platforma tożsamości Microsoft zapewnia obsługę określonych typów tożsamości:
- Konta służbowe, gdy jednostka ma konto w identyfikatorze Entra firmy Microsoft
- Konta osobiste Microsoft (MSA) dla każdego, kto ma konto w Outlook.com, Hotmail, Live, Skype, Xbox itp.
- Tożsamości zewnętrzne w usłudze Microsoft Entra ID dla partnerów (użytkownicy spoza organizacji)
- Firma Microsoft Entra Business to Customer (B2C), która umożliwia tworzenie rozwiązania, które umożliwia klientom wprowadzanie innych dostawców tożsamości. Aplikacje korzystające z usługi Azure AD B2C lub subskrybujące usługę Microsoft Dynamics 365 Fraud Protection za pomocą usługi Azure Active Directory B2C mogą ocenić potencjalnie fałszywe działania po próbach utworzenia nowych kont lub zalogowania się do ekosystemu klienta.
Wymagana część rejestracji aplikacji w usłudze Microsoft Entra ID to wybór obsługiwanych typów kont. Podczas gdy specjalista IT w rolach administratora decyduje, kto może wyrazić zgodę na aplikacje w swojej dzierżawie, ty jako deweloper określ, kto może korzystać z aplikacji na podstawie typu konta. Gdy dzierżawa nie zezwala na rejestrowanie aplikacji w usłudze Microsoft Entra ID, administratorzy udostępniają Ci sposób przekazywania tych szczegółów za pośrednictwem innego mechanizmu.
Podczas rejestrowania aplikacji można wybrać spośród następujących obsługiwanych opcji typu konta.
Accounts in this organizational directory only (O365 only - Single tenant)
Accounts in any organizational directory (Any Azure AD directory - Multitenant)
Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
Personal Microsoft accounts only
Tylko konta w tym katalogu organizacyjnym — jedna dzierżawa
Po wybraniu pozycji Konta tylko w tym katalogu organizacyjnym (tylko usługa O365 — pojedyncza dzierżawa) zezwalasz tylko użytkownikom i gościom z dzierżawy, w której deweloper zarejestrował swoją aplikację. Ta opcja jest najczęściej spotykana w przypadku aplikacji biznesowych (LOB).
Konta tylko w dowolnym katalogu organizacyjnym — wielodostępne
Po wybraniu pozycji Konta w dowolnym katalogu organizacyjnym (dowolny katalog Firmy Microsoft Entra — multitenant) zezwolisz dowolnemu użytkownikowi z dowolnego katalogu Microsoft Entra na logowanie się do aplikacji wielodostępnej. Jeśli chcesz zezwolić tylko użytkownikom z określonych dzierżaw, przefiltrujesz tych użytkowników w kodzie, sprawdzając, czy oświadczenie tid w id_token znajduje się na liście dozwolonych dzierżaw. Aplikacja może używać punktu końcowego organizacji lub wspólnego punktu końcowego do logowania użytkowników w dzierżawie głównej użytkownika. Aby obsługiwać logowanie użytkowników-gości do aplikacji wielodostępnej, należy użyć określonego punktu końcowego dzierżawy dla dzierżawy, w której użytkownik jest gościem, aby zalogować użytkownika.
Konta na dowolnym koncie organizacyjnym i kontach osobistych Microsoft
Po wybraniu pozycji Konta na dowolnym koncie organizacyjnym i osobistych kontach Microsoft (dowolny katalog Microsoft Entra — multitenant) i osobistych kontach Microsoft (np. Skype, Xbox) możesz zezwolić użytkownikowi na logowanie się do aplikacji przy użyciu tożsamości natywnej z dowolnej dzierżawy firmy Microsoft lub konta konsumenta. Takie samo filtrowanie dzierżawy i użycie punktu końcowego mają zastosowanie do tych aplikacji, co w przypadku aplikacji wielodostępnych zgodnie z wcześniejszym opisem.
Tylko osobiste konta Microsoft
Po wybraniu opcji Osobiste konta Microsoft zezwalasz tylko użytkownikom z kontami konsumentów na korzystanie z aplikacji.
Aplikacje dla klientów
Podczas tworzenia rozwiązania w Platforma tożsamości Microsoft, które dociera do klientów, zwykle nie chcesz używać katalogu firmowego. Zamiast tego chcesz, aby klienci byli w osobnym katalogu, aby nie mogli uzyskać dostępu do żadnego z zasobów firmy. Aby spełnić tę potrzebę, firma Microsoft oferuje firmie Microsoft Entra Business klientowi (B2C).
Usługa Azure AD B2C zapewnia tożsamość biznesową jako usługę. Możesz zezwolić użytkownikom na używanie nazwy użytkownika i hasła tylko dla aplikacji. Usługa B2C obsługuje klientów z tożsamościami społecznościowymi w celu zmniejszenia liczby haseł. Klienci korporacyjni mogą obsługiwać, sfederując katalog usługi Azure AD B2C z identyfikatorem Microsoft Entra ID klientów lub dowolnym dostawcą tożsamości obsługującym język SAML (Security Assertion Markup Language) do programu OpenID Connect. W przeciwieństwie do aplikacji wielodostępnej aplikacja nie używa katalogu firmowego klienta, w którym chroni swoje zasoby firmowe. Klienci mogą uzyskiwać dostęp do usługi lub możliwości bez udzielania aplikacji dostępu do zasobów firmy.
To nie tylko deweloper
Podczas definiowania w rejestracji aplikacji, kto może zalogować się do aplikacji, ostatnie powiedzenie pochodzi od pojedynczego użytkownika lub administratorów dzierżawy macierzystej użytkownika. Administratorzy dzierżawy często chcą mieć większą kontrolę nad aplikacją niż tylko to, kto może się zalogować. Na przykład mogą chcieć zastosować zasady dostępu warunkowego do aplikacji lub kontrolować, która grupa zezwala na korzystanie z aplikacji. Aby umożliwić administratorom dzierżawy korzystanie z tej kontrolki, w Platforma tożsamości Microsoft znajduje się drugi obiekt: aplikacja dla przedsiębiorstw. Aplikacje dla przedsiębiorstw są również nazywane jednostkami usługi.
Aplikacje z użytkownikami w innych dzierżawach lub innych kontach konsumentów
Jak pokazano na poniższym diagramie przy użyciu przykładu dwóch dzierżaw (dla fikcyjnych organizacji, Adatum i Contoso), obsługiwane typy kont obejmują konta w dowolnej opcji katalogu organizacyjnego dla aplikacji wielodostępnej, aby umożliwić użytkownikom katalogu organizacyjnego. Innymi słowy, możesz zezwolić użytkownikowi na logowanie się do aplikacji przy użyciu tożsamości natywnej z dowolnego identyfikatora Firmy Microsoft Entra. Jednostka usługi jest tworzona automatycznie w dzierżawie, gdy pierwszy użytkownik z dzierżawy uwierzytelnia się w aplikacji.
Istnieje tylko jedna rejestracja aplikacji lub obiekt aplikacji. Istnieje jednak aplikacja dla przedsiębiorstw lub jednostka usługi (SP) w każdej dzierżawie, która umożliwia użytkownikom logowanie się do aplikacji. Administrator dzierżawy może kontrolować sposób działania aplikacji w dzierżawie.
Zagadnienia dotyczące aplikacji wielodostępnych
Aplikacje wielodostępne loguje użytkowników z dzierżawy głównej użytkownika, gdy aplikacja używa wspólnego punktu końcowego lub organizacji. Aplikacja ma jedną rejestrację aplikacji, jak pokazano na poniższym diagramie. W tym przykładzie aplikacja jest zarejestrowana w dzierżawie Adatum. Użytkownik A z firmy Adatum i użytkownik B firmy Contoso może zalogować się do aplikacji z oczekiwanym użytkownikiem A z firmy Adatum uzyskuje dostęp do danych Adatum, a użytkownik B z firmy Contoso uzyskuje dostęp do danych firmy Contoso.
Jako deweloper ponosisz odpowiedzialność za oddzielenie informacji o dzierżawie. Jeśli na przykład dane firmy Contoso pochodzą z programu Microsoft Graph, użytkownik B z firmy Contoso widzi tylko dane programu Microsoft Graph firmy Contoso. Użytkownik B firmy Contoso nie może uzyskać dostępu do danych programu Microsoft Graph w dzierżawie usługi Adatum, ponieważ platforma Microsoft 365 ma prawdziwe rozdzielenie danych.
Na powyższym diagramie użytkownik B firmy Contoso może zalogować się do aplikacji i uzyskać dostęp do danych firmy Contoso w aplikacji. Aplikacja może używać typowych (lub organizacji) punktów końcowych, dzięki czemu użytkownik natywnie loguje się do swojej dzierżawy, nie wymagając procesu zaproszenia. Użytkownik może uruchomić aplikację i zalogować się do niej i działa po tym, jak użytkownik lub administrator dzierżawy udziela zgody.
Współpraca z użytkownikami zewnętrznymi
Gdy przedsiębiorstwa chcą umożliwić użytkownikom, którzy nie są członkami przedsiębiorstwa w celu uzyskania dostępu do danych z przedsiębiorstwa, korzystają z funkcji Microsoft Entra Business to Business (B2B). Jak pokazano na poniższym diagramie, przedsiębiorstwa mogą zapraszać użytkowników, aby stali się użytkownikami-gośćmi w swojej dzierżawie. Gdy użytkownik zaakceptuje zaproszenie, będzie mógł uzyskać dostęp do danych chronionych przez dzierżawę zapraszającą. Użytkownik nie tworzy oddzielnego poświadczenia w dzierżawie.
Użytkownicy-goście uwierzytelniają się, logując się do swojej dzierżawy głównej, osobistego konta Microsoft lub innego konta dostawcy tożsamości (IDP). Goście mogą również uwierzytelniać się przy użyciu jednorazowego kodu dostępu przy użyciu dowolnej wiadomości e-mail. Po uwierzytelnieniu gości identyfikator firmy Microsoft entra dzierżawy zapraszania zapewnia token dostępu do danych dzierżawy.
Jako deweloper należy wziąć pod uwagę te zagadnienia, gdy aplikacja obsługuje użytkowników-gości:
- Należy użyć punktu końcowego specyficznego dla dzierżawy podczas logowania użytkownika-gościa. Nie można używać typowych, organizacyjnych ani konsumenckich punktów końcowych.
- Tożsamość użytkownika-gościa różni się od tożsamości użytkownika w dzierżawie głównej lub innym dostawcy tożsamości. Oświadczenie
oid
w tokenie dla użytkownika-gościa różni się od tej samej osobyoid
w dzierżawie macierzystej.
Następne kroki
- Jak i dlaczego aplikacje są dodawane do identyfikatora Entra firmy Microsoft, wyjaśnia, w jaki sposób obiekty aplikacji opisują aplikację w identyfikatorze Entra firmy Microsoft.
- Najlepsze rozwiązania dotyczące zabezpieczeń właściwości aplikacji w identyfikatorze Entra firmy Microsoft obejmują właściwości, takie jak identyfikator URI przekierowania, tokeny dostępu, certyfikaty i wpisy tajne, identyfikator URI identyfikatora aplikacji i własność aplikacji.
- Tworzenie aplikacji z podejściem Zero Trust do tożsamości zawiera omówienie uprawnień i najlepszych rozwiązań dotyczących dostępu.
- Uzyskiwanie autoryzacji dostępu do zasobów pomaga zrozumieć, jak najlepiej zapewnić zero trust podczas uzyskiwania uprawnień dostępu do zasobów dla aplikacji.
- Opracowywanie strategii uprawnień delegowanych ułatwia zaimplementowanie najlepszego podejścia do zarządzania uprawnieniami w aplikacji i opracowywania przy użyciu zasad zero trust.
- Opracowywanie strategii uprawnień aplikacji ułatwia podjęcie decyzji o podejściu uprawnień aplikacji do zarządzania poświadczeniami.