Planowanie wdrożenia logowania jednokrotnego

Ten artykuł zawiera informacje, których można użyć do planowania wdrożenia logowania jednokrotnego (SSO) w usłudze Azure Active Directory (Azure AD). Podczas planowania wdrożenia logowania jednokrotnego przy użyciu aplikacji w usłudze Azure AD należy wziąć pod uwagę następujące pytania:

  • Jakie role administracyjne są wymagane do zarządzania aplikacją?
  • Czy certyfikat musi zostać odnowiony?
  • KtoTo należy powiadomić o zmianach związanych z implementacją logowania jednokrotnego?
  • Jakie licencje są potrzebne do zapewnienia skutecznego zarządzania aplikacją?
  • Czy konta użytkowników udostępnionych są używane do uzyskiwania dostępu do aplikacji?
  • Czy rozumiem opcje wdrażania logowania jednokrotnego?

Role administracyjne

Zawsze używaj roli z najmniejszymi dostępnymi uprawnieniami, aby wykonać wymagane zadanie w usłudze Azure AD. Zapoznaj się z różnymi dostępnymi rolami i wybierz odpowiednie role, aby rozwiązać potrzeby każdej osoby dla aplikacji. Niektóre role mogą być stosowane tymczasowo i usuwane po zakończeniu wdrażania.

Persona Role Rola usługi Azure AD (w razie potrzeby)
Administrator pomocy technicznej Obsługa warstwy 1 Brak
Administrator tożsamości Konfigurowanie i debugowanie w przypadku problemów związanych z usługą Azure AD Administrator globalny
Administrator aplikacji Zaświadczenie użytkownika w aplikacji, konfiguracja użytkowników z uprawnieniami Brak
Administratorzy infrastruktury Właściciel przerzucania certyfikatu Administrator globalny
Właściciel firmy/uczestnik projektu Zaświadczenie użytkownika w aplikacji, konfiguracja użytkowników z uprawnieniami Brak

Aby dowiedzieć się więcej na temat ról administracyjnych w usłudze Azure AD, patrz Role wbudowane usługi Azure AD.

Certyfikaty

Po włączeniu federacyjnego logowania jednokrotnego dla aplikacji usługa Azure AD tworzy certyfikat, który jest domyślnie ważny przez trzy lata. W razie potrzeby możesz dostosować datę wygaśnięcia tego certyfikatu. Upewnij się, że masz procesy odnawiania certyfikatów przed ich wygaśnięciem.

Zmieniasz czas trwania certyfikatu w Azure Portal. Pamiętaj, aby udokumentować wygaśnięcie i wiedzieć, jak zarządzać odnawianiem certyfikatu. Ważne jest, aby zidentyfikować odpowiednie role i listy dystrybucyjne poczty e-mail związane z zarządzaniem cyklem życia certyfikatu podpisywania. Zalecane są następujące role:

  • Właściciel do aktualizowania właściwości użytkownika w aplikacji
  • Pomoc techniczna dotycząca rozwiązywania problemów z obsługą rozwiązywania problemów z właścicielem na wezwanie do aplikacji
  • Ściśle monitorowana lista dystrybucyjna poczty e-mail dla powiadomień o zmianach związanych z certyfikatami

Skonfiguruj proces obsługi zmiany certyfikatu między usługą Azure AD a aplikacją. Dzięki temu procesowi można zapobiec awarii lub zminimalizować jej awarię z powodu wygaśnięcia certyfikatu lub wymuszonego przerzucania certyfikatu. Aby uzyskać więcej informacji, zobacz Zarządzanie certyfikatami dla federacyjnego logowania jednokrotnego w Azure Active Directory.

Komunikacja

Komunikacja ma kluczowe znaczenie dla powodzenia każdej nowej usługi. Proaktywnie komunikują się z użytkownikami o tym, jak zmieni się ich środowisko. Porozumuj się, kiedy zmieni się i jak uzyskać pomoc techniczną, jeśli wystąpią problemy. Przejrzyj opcje uzyskiwania dostępu do aplikacji z obsługą logowania jednokrotnego i utwórz komunikację zgodnie z wyborem.

Zaimplementuj plan komunikacji. Upewnij się, że użytkownicy wiedzą, że nadchodzi zmiana, kiedy zostanie ona nadeszła i co należy zrobić teraz. Upewnij się również, że podajesz informacje o sposobie poszukiwania pomocy.

Licencjonowanie

Upewnij się, że aplikacja jest objęta następującymi wymaganiami dotyczącymi licencjonowania:

  • Licencjonowanie usługi Azure AD — logowanie jednokrotne dla wstępnie zintegrowanych aplikacji dla przedsiębiorstw jest bezpłatne. Jednak liczba obiektów w katalogu i funkcjach, które chcesz wdrożyć, może wymagać większej liczby licencji. Aby uzyskać pełną listę wymagań dotyczących licencji, zobacz Azure Active Directory Cennik.

  • Licencjonowanie aplikacji — potrzebne są odpowiednie licencje dla aplikacji, aby spełniały Twoje potrzeby biznesowe. Skontaktuj się z właścicielem aplikacji, aby określić, czy użytkownicy przypisani do aplikacji mają odpowiednie licencje dla swoich ról w aplikacji. Jeśli usługa Azure AD zarządza automatyczną aprowizowaniem na podstawie ról, role przypisane w usłudze Azure AD muszą być zgodne z liczbą licencji należących do aplikacji. Niewłaściwa liczba licencji należących do aplikacji może prowadzić do błędów podczas aprowizacji lub aktualizowania konta użytkownika.

Konta udostępnione

Z perspektywy logowania aplikacje z kontami udostępnionymi nie różnią się od aplikacji dla przedsiębiorstw korzystających z logowania jednokrotnego przy użyciu hasła dla poszczególnych użytkowników. Istnieje jednak więcej kroków wymaganych podczas planowania i konfigurowania aplikacji przeznaczonej do korzystania z kont udostępnionych.

  • Współpracuj z użytkownikami, aby udokumentować następujące informacje:
    • Zestaw użytkowników w organizacji, którzy będą korzystać z aplikacji.
    • Istniejący zestaw poświadczeń w aplikacji skojarzony z zestawem użytkowników.
  • Dla każdej kombinacji zestawu użytkownika i poświadczeń utwórz grupę zabezpieczeń w chmurze lub lokalnie na podstawie Twoich wymagań.
  • Zresetuj poświadczenia udostępnione. Po wdrożeniu aplikacji w usłudze Azure AD użytkownicy indywidualni nie potrzebują hasła konta udostępnionego. Usługa Azure AD przechowuje hasło i należy rozważyć ustawienie go tak, aby było długie i złożone.
  • Skonfiguruj automatyczne przerzucanie hasła, jeśli aplikacja go obsługuje. W ten sposób nawet administrator, który wykonał początkową konfigurację, zna hasło konta udostępnionego.

Opcje logowania jednokrotnego

Istnieje kilka sposobów umożliwiających skonfigurowanie aplikacji na potrzeby logowania jednokrotnego. Wybór metody logowania jednokrotnego zależy od sposobu skonfigurowania aplikacji pod kątem uwierzytelniania.

  • W aplikacjach w chmurze do logowania jednokrotnego mogą być wykorzystywane metody OpenID Connect, OAuth, SAML, a także metody z użyciem hasła lub linków. Funkcję logowania jednokrotnego można również wyłączyć.
  • W aplikacjach lokalnych można korzystać z logowania jednokrotnego opartego na haśle, usługi Integrated Windows Authentication, logowania z użyciem nagłówka lub linków. Opcje lokalne działają, gdy aplikacje są skonfigurowane pod kątem serwera proxy aplikacji.

Ten schemat blokowy może pomóc w podjęciu decyzji, która metoda logowania jednokrotnego jest najlepsza w Twojej sytuacji.

Decision flowchart for single sign-on method

Dostępne są następujące protokoły logowania jednokrotnego:

  • OpenID Połączenie i OAuth — wybierz pozycję OpenID Połączenie i OAuth 2.0, jeśli aplikacja, z którą nawiązujesz połączenie, obsługuje ją. Aby uzyskać więcej informacji, zobacz Protokoły OAuth 2.0 i OpenID Połączenie w Platforma tożsamości Microsoft. Aby uzyskać instrukcje implementowania logowania jednokrotnego opartego na protokole OpenID Połączenie, zobacz Konfigurowanie logowania jednokrotnego opartego na protokole OIDC dla aplikacji w Azure Active Directory.

  • SAML — wybierz protokół SAML zawsze, gdy jest to możliwe dla istniejących aplikacji, które nie korzystają z openID Połączenie lub OAuth. Aby uzyskać więcej informacji, zobacz Single Sign-On SAML protocol (Pojedynczy protokół SAML). Aby zapoznać się z szybkim wprowadzeniem do implementowania logowania jednokrotnego SAML, zobacz Szybki start: konfigurowanie logowania jednokrotnego opartego na protokole SAML dla aplikacji w Azure Active Directory.

  • Oparte na hasłach — wybierz opcję opartą na hasłach, gdy aplikacja ma stronę logowania HTML. Logowanie jednokrotne oparte na hasłach jest również nazywane przechowywaniem haseł. Logowanie jednokrotne oparte na hasłach umożliwia zarządzanie dostępem użytkowników i hasłami do aplikacji internetowych, które nie obsługują federacji tożsamości. Jest to również przydatne, gdy kilku użytkowników musi współużytkować jedno konto, na przykład na kontach aplikacji społecznościowych organizacji.

    Logowanie jednokrotne oparte na hasłach obsługuje aplikacje wymagające wielu pól logowania dla aplikacji, które wymagają więcej niż tylko pól nazwy użytkownika i hasła do logowania. Możesz dostosować etykiety pól nazwy użytkownika i hasła, które użytkownicy widzą na Moje aplikacje po wprowadzeniu poświadczeń. Aby uzyskać instrukcje implementowania logowania jednokrotnego opartego na hasłach, zobacz Logowanie jednokrotne oparte na hasłach.

  • Połączone — wybierz link, gdy aplikacja jest skonfigurowana do logowania jednokrotnego w innej usłudze dostawcy tożsamości. Opcja połączenia umożliwia skonfigurowanie miejsca docelowego, gdy użytkownik wybierze aplikację w portalach organizacji. Można dodać połączenie do niestandardowej aplikacji internetowej, która obecnie korzysta z federacji, na przykład z usług Active Directory Federation Services (AD FS).

    Można również dodać połączenia do określonych stron internetowych, które mają być wyświetlane na panelach dostępu użytkowników, oraz do aplikacji, która nie wymaga uwierzytelniania. Opcja Połączone nie zapewnia funkcji logowania za pomocą poświadczeń usługi Azure AD. Aby uzyskać instrukcje implementowania połączonego logowania jednokrotnego, zobacz Połączone logowanie jednokrotne.

  • Wyłączone — wybierz wyłączone logowanie jednokrotne, gdy aplikacja nie jest gotowa do skonfigurowania na potrzeby logowania jednokrotnego.

  • Zintegrowane uwierzytelnianie Windows (IWA) — wybierz logowanie jednokrotne IWA dla aplikacji korzystających z usługi IWA lub aplikacji obsługujących oświadczenia. Aby uzyskać więcej informacji, zobacz Delegowanie ograniczone protokołu Kerberos na potrzeby logowania jednokrotnego do aplikacji przy użyciu serwer proxy aplikacji.

  • Oparte na nagłówku — wybierz logowanie jednokrotne oparte na nagłówku, gdy aplikacja używa nagłówków do uwierzytelniania. Aby uzyskać więcej informacji, zobacz Logowanie jednokrotne oparte na nagłówku.

Następne kroki