Udostępnij za pośrednictwem

Scenariusz — zabezpieczanie dostępu do platform i aplikacji SAP przy użyciu identyfikatora Entra firmy Microsoft

  • Artykuł

Ten dokument zawiera porady dotyczące projektowania technicznego i konfigurowania platform i aplikacji SAP podczas korzystania z identyfikatora Entra firmy Microsoft jako podstawowej usługi uwierzytelniania użytkownika dla usług SAP Cloud Identity Services. Usługi SAP Cloud Identity Services obejmują uwierzytelnianie tożsamości, aprowizowanie tożsamości, katalog tożsamości i zarządzanie autoryzacją. Dowiedz się więcej na temat początkowej konfiguracji uwierzytelniania w samouczku dotyczącym integracji logowania jednokrotnego firmy Microsoft z usługą SAP Cloud Identity Services. Aby uzyskać więcej informacji na temat aprowizacji i innych scenariuszy, zobacz Planowanie wdrażania usługi Microsoft Entra na potrzeby aprowizacji użytkowników przy użyciu aplikacji źródłowych i docelowych SAP oraz zarządzania dostępem do aplikacji SAP.

Terminologia używana w tym przewodniku

Skrót opis
BTP SAP Business Technology Platform to platforma innowacji zoptymalizowana pod kątem aplikacji SAP w chmurze. Większość omówionych tutaj technologii SAP jest częścią protokołu BTP. Produkty formalnie znane jako SAP Cloud Platform są częścią oprogramowania SAP BTP.
IAS SAP Cloud Identity Services — Identity Authentication, składnik usług SAP Cloud Identity Services, to usługa w chmurze służąca do uwierzytelniania, logowania jednokrotnego i zarządzania użytkownikami w chmurze SAP i aplikacjach lokalnych. Usługa IAS pomaga użytkownikom uwierzytelniać się we własnych wystąpieniach usługi SAP BTP jako serwer proxy integrujący się z logowaniem jednokrotnym firmy Microsoft Entra.
IPS SAP Cloud Identity Services — identity provisioning, składnik usług SAP Cloud Identity Services, to usługa w chmurze, która ułatwia aprowizowanie tożsamości i ich autoryzacji w chmurze SAP i aplikacji lokalnej.
XSUAA Rozszerzone usługi dla konta użytkownika i uwierzytelniania usługi Cloud Foundry. Cloud Foundry, platforma jako usługa (PaaS), którą można wdrożyć w różnych infrastrukturach, to środowisko, w którym sap zbudował platformę SAP Business Technology Platform. XSUAA to wielodostępny serwer autoryzacji OAuth, który jest centralnym składnikiem infrastruktury środowiska Cloud Foundry. XSUAA zapewnia uwierzytelnianie i autoryzację użytkownika biznesowego w ramach protokołu SAP BTP.
Fiori Środowisko użytkownika oparte na sieci Web oprogramowania SAP (w przeciwieństwie do środowiska opartego na komputerze).

Omówienie

Istnieje wiele usług i składników w stosie technologii SAP i Microsoft, które odgrywają rolę w scenariuszach uwierzytelniania i autoryzacji użytkownika. Główne usługi są wymienione na poniższym diagramie.

Omówienie środowiska SAP

Ponieważ istnieje wiele permutacji możliwych scenariuszy do skonfigurowania, koncentrujemy się na jednym scenariuszu, który jest zgodny ze strategią firmy Microsoft Entra identity first. Założymy następujące założenia:

  • Chcesz centralnie zarządzać wszystkimi tożsamościami i tylko z identyfikatora Entra firmy Microsoft.
  • Chcesz jak najwięcej zmniejszyć nakłady pracy konserwacyjne i zautomatyzować uwierzytelnianie i dostęp do aplikacji w firmie Microsoft i oprogramowaniu SAP.
  • Ogólne wskazówki dotyczące identyfikatora entra firmy Microsoft z usługą IAS dotyczą aplikacji wdrożonych w aplikacjach BTP i SAP SaaS skonfigurowanych w usłudze IAS. Konkretne zalecenia będą również udostępniane tam, gdzie ma zastosowanie do protokołu BTP (na przykład przy użyciu mapowań ról z grupami Firmy Microsoft Entra) i aplikacji SAP SaaS (na przykład przy użyciu usługi aprowizacji tożsamości na potrzeby autoryzacji opartej na rolach).
  • Zakładamy również, że użytkownicy są już aprowizowani w usłudze Microsoft Entra ID i w przypadku wszystkich systemów SAP, które wymagają aprowizacji użytkowników do działania. Niezależnie od tego, jak to zostało osiągnięte: aprowizowanie mogło być realizowane ręcznie, z lokalna usługa Active Directory za pośrednictwem programu Microsoft Entra Connect lub za pośrednictwem systemów HR, takich jak SAP SuccessFactors. W związku z tym w tym dokumencie rozwiązanie SuccessFactors jest uznawane za aplikację podobną do innych, do których (istniejący) użytkownicy będą się logować. Nie obejmujemy rzeczywistej aprowizacji użytkowników z rozwiązania SuccessFactors do identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji na temat dołączania użytkowników do identyfikatora Entra firmy Microsoft do użycia z obciążeniami SAP, zobacz Planowanie wdrażania usługi Microsoft Entra na potrzeby aprowizacji użytkowników za pomocą aplikacji źródłowych i docelowych SAP oraz zarządzania dostępem do aplikacji SAP.

Na podstawie tych założeń skupiamy się głównie na produktach i usługach przedstawionych na poniższym diagramie. Są to różne składniki, które są najbardziej istotne dla uwierzytelniania i autoryzacji w środowisku opartym na chmurze.

Usługi SAP w zakresie

Jeśli używasz rozwiązania SAP Identity Management (IDM), możesz migrować scenariusze zarządzania tożsamościami z programu SAP IDM do usługi Microsoft Entra. Aby uzyskać więcej informacji, zobacz Migrowanie scenariuszy zarządzania tożsamościami z programu SAP IDM do usługi Microsoft Entra.

Uwaga

Większość wskazówek dotyczy również usługi Azure Active Directory B2C , ale istnieją pewne istotne różnice. Aby uzyskać więcej informacji, zobacz Używanie usługi Azure AD B2C jako dostawcy tożsamości.

Ostrzeżenie

Należy pamiętać o limitach asercji SAP SAML i wpływie długości nazw kolekcji ról SAP Cloud Foundry i ilości kolekcji proxied przez grupy w usłudze SAP Cloud Identity Service. Aby uzyskać więcej informacji, zobacz uwaga SAP 2732890 w oprogramowaniu SAP for Me. Przekroczone limity powodują problemy z autoryzacją.

Zalecenia

Podsumowanie

1 — Używanie uwierzytelniania federacyjnego w aplikacjach SAP Business Technology Platform i SAP SaaS za pomocą usługi SAP Identity Authentication Service

Kontekst

Aplikacje w usłudze BTP mogą używać dostawców tożsamości za pośrednictwem konfiguracji zaufania do uwierzytelniania użytkowników przy użyciu protokołu SAML 2.0 między protokołem BTP/XSUAA a dostawcą tożsamości. Należy pamiętać, że obsługiwany jest tylko protokół SAML 2.0, mimo że protokół OpenID Connect jest używany między samą aplikacją a protokołem BTP/XSUAA (nie dotyczy tego kontekstu).

W usłudze BTP możesz skonfigurować konfigurację zaufania w usłudze SAP Cloud Identity Services — Identity Authentication (ustawienie domyślne), ale gdy autorytatywny katalog użytkowników to Microsoft Entra ID, możesz skonfigurować federację , aby użytkownicy mogli logować się przy użyciu istniejących kont microsoft Entra.

Oprócz federacji możesz również skonfigurować aprowizację użytkowników, aby użytkownicy firmy Microsoft Entra aprowizować z góry w usłudze BTP. Nie ma jednak natywnej obsługi tej funkcji (tylko w przypadku usługi Microsoft Entra ID —> SAP Identity Authentication Service). Zintegrowane rozwiązanie z natywną obsługą będzie usługą BTP Identity Provisioning Service. Aprowizowanie kont użytkowników z góry może być przydatne do celów autoryzacji (na przykład w celu dodania użytkowników do ról). Jednak w zależności od wymagań można to osiągnąć w przypadku grup firmy Microsoft Entra (patrz poniżej), co może oznaczać, że nie potrzebujesz aprowizacji użytkowników w ogóle.

Podczas konfigurowania relacji federacyjnej istnieje wiele opcji:

  • Możesz federować do identyfikatora Entra firmy Microsoft bezpośrednio z BTP/XSUAA.
  • Możesz zdecydować się na federację z usługą IAS, która z kolei jest skonfigurowana do federacji z identyfikatorem Microsoft Entra jako dostawcą tożsamości firmowej (znanym również jako "serwer proxy SAML").

W przypadku aplikacji SAP SaaS usługa IAS jest aprowizowana i wstępnie skonfigurowana do łatwego dołączania użytkowników końcowych. (Przykłady z nich to SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud i inne). Ten scenariusz jest mniej złożony, ponieważ usługa IAS jest bezpośrednio połączona z aplikacją docelową i nie jest połączona z architekturą XSUAA. W każdym razie te same reguły dotyczą tej konfiguracji co identyfikator Entra firmy Microsoft z ogólnie usługą IAS.

Co zalecamy?

Gdy autorytatywny katalog użytkowników to Microsoft Entra ID, zalecamy skonfigurowanie konfiguracji zaufania w usłudze BTP w kierunku IAS. Usługa IAS z kolei jest skonfigurowana do federacji z identyfikatorem Entra firmy Microsoft jako dostawcą tożsamości firmowej.

Konfiguracja zaufania sap

W konfiguracji zaufania w usłudze BTP zalecamy włączenie opcji "Tworzenie użytkowników w tle podczas logowania". Dzięki temu użytkownicy, którzy jeszcze nie zostali utworzeni w usłudze BTP, automatycznie otrzymają konto po pierwszym zalogowaniu się za pośrednictwem identyfikatora IAS/Microsoft Entra. Jeśli to ustawienie zostanie wyłączone, tylko użytkownicy wstępnie aprowizowani będą mogli się zalogować.

Dlaczego to zalecenie?

W przypadku korzystania z federacji można zdefiniować konfigurację zaufania na poziomie konta podrzędnego BTP. W takim przypadku należy powtórzyć konfigurację dla innego konta podrzędnego, którego używasz. Korzystając z usługi IAS jako konfiguracji zaufania pośredniego, możesz skorzystać ze scentralizowanej konfiguracji w wielu kontach podrzędnych i można użyć funkcji IAS, takich jak uwierzytelnianie oparte na ryzyku i scentralizowane wzbogacanie atrybutów asercji. Aby chronić środowisko użytkownika, te zaawansowane funkcje zabezpieczeń powinny być wymuszane tylko w jednej lokalizacji. Może to być usługa IAS lub przechowywanie identyfikatora Entra firmy Microsoft jako pojedynczego autorytatywnego magazynu użytkowników (podobnie jak w przypadku założenia tego artykułu), byłoby to centralnie obsługiwane przez usługę Microsoft Entra Conditional Access Management.

Uwaga: w przypadku IAS każde konto podrzędne jest uznawane za "aplikację", mimo że w ramach tego konta podrzędnego można wdrożyć co najmniej jedną aplikację. W usłudze IAS każda taka aplikacja może być skonfigurowana na potrzeby federacji z tym samym dostawcą tożsamości firmowej (w tym przypadku identyfikator Entra firmy Microsoft).

Podsumowanie implementacji

W identyfikatorze Entra firmy Microsoft:

  • Opcjonalnie skonfiguruj usługę Microsoft Entra ID na potrzeby bezproblemowego logowania jednokrotnego (Bezproblemowe logowanie jednokrotne), które automatycznie loguje użytkowników, gdy znajdują się na swoich urządzeniach firmowych połączonych z siecią firmową. Gdy ta funkcja jest włączona, użytkownicy nie muszą wpisywać haseł, aby zalogować się do usługi Microsoft Entra ID, a zwykle nie muszą nawet wpisywać swoich nazw użytkownika.

W usłudze Microsoft Entra ID i IAS:

  • Postępuj zgodnie z dokumentacją, aby połączyć identyfikator Entra firmy Microsoft z usługą IAS w trybie federacji (proxy) (DOKUMENTACJA SAP, Microsoft Doc). Zwróć uwagę na NameID ustawienie konfiguracji logowania jednokrotnego w usłudze Microsoft Entra ID, ponieważ nazwy UPN nie muszą być adresami e-mail.
  • Skonfiguruj opcję "Aplikacja dołączona", aby używać identyfikatora Entra firmy Microsoft, przechodząc do strony "Uwierzytelnianie warunkowe" i ustawiając wartość "Default Authenticating Identity Provider" na dostawcę tożsamości firmowej reprezentującego katalog Microsoft Entra.

W BTP:

  • Skonfiguruj konfigurację zaufania w usłudze IAS (SAP doc) i upewnij się, że opcja "Dostępne dla logowania użytkowników" i "Tworzenie użytkowników w tle podczas logowania" jest włączona.
  • Opcjonalnie wyłącz opcję "Dostępne dla logowania użytkownika" w domyślnej konfiguracji zaufania "usługa SAP ID Service", aby użytkownicy zawsze uwierzytelniali się za pośrednictwem identyfikatora Entra firmy Microsoft i nie są wyświetlane na ekranie, aby wybrać dostawcę tożsamości.

2 — Użyj identyfikatora Entra firmy Microsoft do uwierzytelniania i IAS/BTP na potrzeby autoryzacji

Kontekst

Jeśli usługi BTP i IAS zostały skonfigurowane do uwierzytelniania użytkowników za pośrednictwem federacji w kierunku identyfikatora Entra firmy Microsoft, istnieje wiele opcji konfigurowania autoryzacji:

  • W usłudze Microsoft Entra ID możesz przypisać użytkowników i grupy firmy Microsoft do aplikacji dla przedsiębiorstw reprezentującej wystąpienie rozwiązania SAP IAS w usłudze Microsoft Entra ID.
  • W usłudze IAS można użyć uwierzytelniania opartego na ryzyku, aby zezwolić na logowanie lub zablokować je, a tym samym uniemożliwić dostęp do aplikacji w protokole BTP.
  • W usłudze BTP można użyć kolekcji ról, aby zdefiniować, którzy użytkownicy i grupy mogą uzyskiwać dostęp do aplikacji i uzyskiwać określone role.

Co zalecamy?

Zalecamy, aby nie umieszczać żadnej autoryzacji bezpośrednio w firmie Microsoft Entra i jawnie wyłączyć opcję "Wymagane przypisanie użytkownika" w aplikacji dla przedsiębiorstw w usłudze Microsoft Entra ID. Należy pamiętać, że w przypadku aplikacji SAML to ustawienie jest domyślnie włączone, dlatego należy wykonać jawne działania, aby je wyłączyć.

Dlaczego to zalecenie?

Gdy aplikacja jest federacyjna za pośrednictwem IAS, z punktu widzenia identyfikatora Entra firmy Microsoft użytkownik jest zasadniczo "uwierzytelnianie w usłudze IAS" podczas przepływu logowania. Oznacza to, że identyfikator Entra firmy Microsoft nie zawiera informacji o ostatecznej aplikacji BTP, do której użytkownik próbuje się zalogować. Oznacza to również, że autoryzacja w identyfikatorze Entra firmy Microsoft może służyć tylko do wykonywania bardzo grubszej autoryzacji, na przykład zezwalając użytkownikowi na logowanie się do dowolnej aplikacji w usłudze BTP lub brak. Podkreśla to również strategię sap w celu odizolowania aplikacji i mechanizmów uwierzytelniania na poziomie konta podrzędnego BTP.

Chociaż może to być prawidłową przyczyną użycia "Wymagane przypisanie użytkownika", oznacza to, że obecnie istnieją potencjalnie dwa różne miejsca, w których należy przechowywać informacje o autoryzacji: zarówno w identyfikatorze Entra firmy Microsoft w aplikacji dla przedsiębiorstw (gdzie dotyczy wszystkich aplikacji BTP), jak również w każdym podkonta BTP. Może to prowadzić do nieporozumień i błędów konfiguracji, w których ustawienia autoryzacji są aktualizowane w jednym miejscu, ale nie w drugim. Na przykład: użytkownik był dozwolony w usłudze BTP, ale nie został przypisany do aplikacji w identyfikatorze Entra firmy Microsoft, co spowodowało niepowodzenie uwierzytelniania.

Podsumowanie implementacji

W aplikacji Microsoft Entra Enterprise reprezentującej relację federacyjną z usługą IAS wyłącz opcję "Wymagane przypisanie użytkownika". Oznacza to również, że można bezpiecznie pominąć przypisywanie użytkowników.

3 — Używanie grup entra firmy Microsoft do autoryzacji za pośrednictwem kolekcji ról w IAS/BTP

Kontekst

Jeśli chcesz skonfigurować autoryzację dla aplikacji BTP, istnieje wiele opcji:

  • Możesz skonfigurować szczegółową kontrolę dostępu wewnątrz samej aplikacji na podstawie zalogowanego użytkownika.
  • Dostęp można określić za pomocą ról i kolekcji ról w protokole BTP na podstawie przypisań użytkowników lub przypisań grup.

Ostateczna implementacja może używać kombinacji obu strategii. Jednak w przypadku przypisania za pomocą kolekcji ról można to zrobić dla użytkownika według użytkownika lub użyć grup skonfigurowanego dostawcy tożsamości.

Co zalecamy?

Jeśli chcesz użyć identyfikatora Entra firmy Microsoft jako autorytatywnego źródła do szczegółowej autoryzacji, zalecamy używanie grup Firmy Microsoft Entra i przypisywanie ich do kolekcji ról w usłudze BTP. Udzielanie użytkownikom dostępu do niektórych aplikacji oznacza po prostu dodanie ich do odpowiednich grup Firmy Microsoft Entra bez konieczności dalszej konfiguracji w IAS/BTP.

W przypadku tej konfiguracji zalecamy użycie identyfikatora grupy entra firmy Microsoft (identyfikatora obiektu) jako unikatowego identyfikatora grupy, a nie nazwy wyświetlanej ("sAMAccountName"). Oznacza to, że należy użyć identyfikatora grupy jako asercji "Grupy" w tokenie SAML wystawionym przez identyfikator Firmy Microsoft Entra. Ponadto identyfikator grupy jest używany do przypisania do kolekcji ról w BTP.

Korzystanie z kolekcji ról w oprogramowaniu SAP

Dlaczego to zalecenie?

Jeśli przypiszesz użytkowników bezpośrednio do kolekcji ról w usłudze BTP, nie będziesz centralizować decyzji dotyczących autoryzacji w identyfikatorze Entra firmy Microsoft. Oznacza to również, że użytkownik musi już istnieć w usłudze IAS, zanim będzie mógł zostać przypisany do kolekcji ról w usłudze BTP — i biorąc pod uwagę, że zalecamy federację zamiast aprowizacji użytkowników, oznacza to, że konto w tle użytkownika może jeszcze nie istnieć w usłudze IAS w momencie, gdy chcesz wykonać przypisanie użytkownika. Używanie grup Entra firmy Microsoft i przypisywanie ich do kolekcji ról eliminuje te problemy.

Przypisywanie grup do kolekcji ról może wydawać się sprzeczne z wcześniejszym zaleceniem, aby nie używać identyfikatora Entra firmy Microsoft do autoryzacji. Nawet w tym przypadku jednak decyzja o autoryzacji jest nadal podejmowana w BTP, to tylko dlatego, że decyzja jest teraz oparta na członkostwie w grupie utrzymywanym w identyfikatorze Microsoft Entra ID.

Zalecamy użycie identyfikatora grupy entra firmy Microsoft, a nie jej nazwy, ponieważ identyfikator grupy jest globalnie unikatowy, niezmienny i nigdy nie może być ponownie używany dla innej grupy później; mając na uwadze, że użycie nazwy grupy może prowadzić do problemów podczas zmiany nazwy, a w przypadku usunięcia grupy istnieje ryzyko związane z bezpieczeństwem i utworzenie innej grupy o tej samej nazwie, ale z użytkownikami, którzy nie powinni mieć dostępu do aplikacji.

Podsumowanie implementacji

W identyfikatorze Entra firmy Microsoft:

  • Utwórz grupy, do których można dodać użytkowników, którzy potrzebują dostępu do aplikacji w usłudze BTP (na przykład utwórz grupę Microsoft Entra dla każdej kolekcji ról w usłudze BTP).
  • W aplikacji Microsoft Entra Enterprise reprezentującej relację federacyjną z usługą IAS skonfiguruj atrybuty użytkownika SAML i oświadczenia, aby dodać oświadczenie grupy dla grup zabezpieczeń:

    • Ustaw atrybut Źródłowy na "Identyfikator grupy" i nazwę na Groups (pisownia dokładnie tak, z wielkimi literami "G").

    • Ponadto w celu zachowania małych ładunków oświadczeń i uniknięcia wystąpienia ograniczenia polegającego na tym, że identyfikator Entra firmy Microsoft ograniczy liczbę oświadczeń grupy do 150 w asercji SAML, zdecydowanie zalecamy ograniczenie grup zwracanych w oświadczeniach tylko do tych grup, które zostały jawnie przypisane:

      • W obszarze "Które grupy skojarzone z użytkownikiem powinny być zwracane w oświadczeniu?" odpowiedź z komunikatem "Grupy przypisane do aplikacji". Następnie dla grup, które chcesz dołączyć jako oświadczenia, przypisz je do aplikacji dla przedsiębiorstw przy użyciu sekcji "Użytkownicy i grupy" i wybierz pozycję "Dodaj użytkownika/grupę".

      Konfiguracja oświadczenia grupy firmy Microsoft

W usłudze IAS:

  • W konfiguracji dostawcy tożsamości firmowej w obszarze Opcje federacji tożsamości upewnij się, że wyłączysz opcję "Użyj magazynu użytkowników uwierzytelniania tożsamości"; w przeciwnym razie informacje o grupie z identyfikatora Entra firmy Microsoft nie zostaną zachowane w tokenie SAML w kierunku protokołu BTP i autoryzacja zakończy się niepowodzeniem.

Uwaga

Jeśli musisz użyć magazynu użytkowników usługi Identity Authentication (na przykład w celu uwzględnienia oświadczeń, których nie można uzyskać ze źródła z identyfikatora Entra firmy Microsoft, ale które są dostępne w magazynie użytkowników IAS), możesz zachować to ustawienie włączone. W takim przypadku należy jednak skonfigurować atrybuty domyślne wysyłane do aplikacji , aby uwzględnić odpowiednie oświadczenia pochodzące z identyfikatora Entra firmy Microsoft (na przykład z formatem ${corporateIdP.Groups} ).

W BTP:

  • W kolekcjach ról używanych przez aplikacje w tym subaccount zamapuj kolekcje ról na grupy użytkowników, dodając konfigurację dostawcy tożsamości IAS i ustawiając nazwę na identyfikator grupy (identyfikator obiektu) grupy Microsoft Entra.

Uwaga

Jeśli masz inne oświadczenie w identyfikatorze Entra firmy Microsoft, aby zawierać informacje o autoryzacji, które mają być używane w usłudze BTP, nie musisz używać Groups nazwy oświadczenia. Jest to używane przez usługę BTP podczas mapowania kolekcji ról na grupy użytkowników, jak pokazano powyżej, ale można również mapować kolekcje ról na atrybuty użytkownika, co zapewnia nieco większą elastyczność.

4 — Użyj pojedynczego konta podrzędnego BTP tylko dla aplikacji, które mają podobne wymagania dotyczące tożsamości

Kontekst

W ramach protokołu BTP każdy podkonto może zawierać wiele aplikacji. Jednak z punktu widzenia IAS "Aplikacja w pakiecie" jest kompletnym podkonta BTP, a nie bardziej szczegółowymi aplikacjami w nim. Oznacza to, że wszystkie ustawienia zaufania, uwierzytelnianie i konfiguracja dostępu, a także opcje znakowania i układu w usłudze IAS mają zastosowanie do wszystkich aplikacji w ramach tego konta podrzędnego. Podobnie wszystkie konfiguracje zaufania i kolekcje ról w usłudze BTP mają również zastosowanie do wszystkich aplikacji w ramach tego konta podrzędnego.

Co zalecamy?

Zalecamy łączenie wielu aplikacji w ramach jednego konta podrzędnego BTP tylko wtedy, gdy mają podobne wymagania dotyczące poziomu tożsamości (użytkownicy, grupy, dostawcy tożsamości, role, konfiguracja zaufania, znakowanie, ...).

Dlaczego to zalecenie?

Łącząc wiele aplikacji, które mają bardzo różne wymagania dotyczące tożsamości w ramach jednego konta podrzędnego w usłudze BTP, można utworzyć konfigurację, która jest niezabezpieczona lub może być łatwiej nieprawidłowo skonfigurowana. Na przykład: jeśli konfiguracja zmieni się na zasób udostępniony, taki jak dostawca tożsamości, zostanie utworzona dla pojedynczej aplikacji w usłudze BTP, ma to wpływ na wszystkie aplikacje korzystające z tego zasobu udostępnionego.

Podsumowanie implementacji

Uważnie zastanów się, jak chcesz zgrupować wiele aplikacji w ramach podkonta w usłudze BTP. Aby uzyskać więcej informacji, zobacz dokumentację modelu kont SAP.

5 — Użyj dzierżawy produkcyjnej IAS dla wszystkich użytkowników końcowych uwierzytelniania i autoryzacji

Kontekst

Podczas pracy z usługą IAS zazwyczaj masz dzierżawę produkcyjną i tworzenie i testowanie. W przypadku różnych kont podrzędnych lub aplikacji w usłudze BTP możesz wybrać dostawcę tożsamości (dzierżawę IAS) do użycia.

Co zalecamy?

Zalecamy, aby zawsze używać dzierżawy IAS w środowisku produkcyjnym do interakcji z użytkownikami końcowymi, nawet w kontekście wersji dewelopera/testowania lub środowiska aplikacji , do której muszą się zalogować.

Zalecamy używanie innych dzierżaw IAS tylko do testowania konfiguracji związanej z tożsamością, która musi być wykonywana w izolacji od dzierżawy produkcyjnej.

Dlaczego to zalecenie?

Ponieważ usługa IAS to scentralizowany składnik, który został skonfigurowany do federacji z identyfikatorem Entra firmy Microsoft, istnieje tylko jedno miejsce, w którym należy skonfigurować i utrzymywać konfigurację federacji i tożsamości. Duplikowanie tego w innych dzierżawach IAS może prowadzić do błędnych konfiguracji lub niespójności w dostępie użytkowników końcowych między środowiskami.

6 — Definiowanie procesu przerzucania certyfikatów podpisywania SAML

Kontekst

Podczas konfigurowania federacji między usługą Microsoft Entra ID i IAS, a także między usługami IAS i BTP, metadane JĘZYKA SAML są wymieniane, które zawierają certyfikaty X.509 używane do szyfrowania i podpisów kryptograficznych tokenów SAML wysyłanych między obie strony. Te certyfikaty mają daty wygaśnięcia i muszą być okresowo aktualizowane (nawet w sytuacjach awaryjnych, gdy certyfikat został naruszony na przykład).

Uwaga: domyślny okres ważności początkowego certyfikatu firmy Microsoft Entra używanego do podpisywania asercji SAML wynosi 3 lata (i należy pamiętać, że certyfikat jest specyficzny dla aplikacji dla przedsiębiorstw, w przeciwieństwie do tokenów OpenID Connect i OAuth 2.0 podpisanych przez certyfikat globalny w identyfikatorze Entra firmy Microsoft). Możesz wygenerować nowy certyfikat z inną datą wygaśnięcia lub utworzyć i zaimportować własny certyfikat.

Po wygaśnięciu certyfikatów nie można ich już używać, a nowe certyfikaty muszą być skonfigurowane. W związku z tym należy ustanowić proces, aby zachować konfigurację certyfikatu wewnątrz jednostki uzależnionej (która musi zweryfikować podpisy) na bieżąco z rzeczywistymi certyfikatami używanymi do podpisywania tokenów JĘZYKA SAML.

W niektórych przypadkach jednostka uzależniona może to zrobić automatycznie, udostępniając mu punkt końcowy metadanych, który dynamicznie zwraca najnowsze informacje o metadanych — czyli zazwyczaj publicznie dostępny adres URL, z którego jednostka uzależniona może okresowo pobierać metadane i aktualizować wewnętrzny magazyn konfiguracji.

Jednak usługa IAS umożliwia skonfigurowanie tylko dostawców tożsamości firmowych za pośrednictwem importu pliku XML metadanych, ale nie obsługuje udostępniania punktu końcowego metadanych na potrzeby dynamicznego pobierania metadanych firmy Microsoft (na przykład https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Podobnie protokół BTP nie zezwala na skonfigurowanie nowej konfiguracji zaufania z punktu końcowego metadanych IAS (na przykład https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), wymaga również jednorazowego przekazania pliku XML metadanych.

Co zalecamy?

Podczas konfigurowania federacji tożsamości między dowolnymi dwoma systemami (na przykład Microsoft Entra ID i IAS oraz IAS i BTP) upewnij się, że przechwycono datę wygaśnięcia używanych certyfikatów. Upewnij się, że te certyfikaty można zastąpić z wyprzedzeniem i że istnieje udokumentowany proces aktualizowania nowych metadanych we wszystkich jednostkach uzależnionych, które zależą od tych certyfikatów.

Jak wspomniano wcześniej, zalecamy skonfigurowanie konfiguracji zaufania w usłudze BTP w kierunku IAS, która z kolei jest skonfigurowana do federacji z identyfikatorem Entra firmy Microsoft jako dostawcą tożsamości firmowej. W takim przypadku ważne są następujące certyfikaty (które są używane do podpisywania i szyfrowania SAML):

  • Certyfikat konta podrzędnego w usłudze BTP: po wprowadzeniu tej zmiany należy zaktualizować konfigurację SAML 2.0 aplikacji w usłudze IAS.
  • Certyfikat dzierżawy w usłudze IAS: po wprowadzeniu zmian należy zaktualizować konfigurację PROTOKOŁU SAML 2.0 aplikacji dla przedsiębiorstw w usłudze Microsoft Entra ID i konfigurację zaufania w usłudze BTP.
  • Certyfikat aplikacji dla przedsiębiorstw w usłudze Microsoft Entra ID: po wprowadzeniu zmian należy zaktualizować konfigurację SAML 2.0 dostawcy tożsamości firmowej w usłudze IAS.

Przerzucenie certyfikatów podpisywania SAML

Oprogramowanie SAP zawiera przykładowe implementacje powiadomień o certyfikatach klienta z integracją z chmurą SAP i obsługą niemal wygasania. Można to dostosować za pomocą usług Azure Integration Services lub PowerAutomate. Należy jednak dostosować je do pracy z certyfikatami serwera. Takie podejście wymaga implementacji niestandardowej.

Dlaczego to zalecenie?

Jeśli certyfikaty mogą wygasać lub gdy są zastępowane w czasie, ale jednostki uzależnione, które są od nich zależne, nie są aktualizowane przy użyciu nowych informacji o certyfikacie, użytkownicy nie będą już mogli logować się do żadnej aplikacji za pośrednictwem federacji. Może to oznaczać znaczny przestój dla wszystkich użytkowników podczas przywracania usługi przez ponowne skonfigurowanie metadanych.

Podsumowanie implementacji

Dodaj adres powiadomienia e-mail o wygaśnięciu certyfikatu w identyfikatorze Entra firmy Microsoft i ustaw go na skrzynkę pocztową grupy, aby nie została wysłana do pojedynczej osoby (która może nawet nie mieć konta przez czas, w którym certyfikat wkrótce wygaśnie). Domyślnie tylko użytkownik, który utworzył aplikację dla przedsiębiorstw, otrzyma powiadomienie.

Rozważ utworzenie automatyzacji w celu wykonania całego procesu przerzucania certyfikatów. Można na przykład okresowo sprawdzać wygasające certyfikaty i zastępować je podczas aktualizowania wszystkich jednostek uzależnionych przy użyciu nowych metadanych.

Używanie usługi Azure AD B2C jako dostawcy tożsamości

Usługa Azure Active Directory B2C zapewnia tożsamość biznesową jako usługę. Biorąc pod uwagę, że integracja z usługą Azure AD B2C jest podobna do tego, jak umożliwić użytkownikom przedsiębiorstwa logowanie się przy użyciu identyfikatora Entra firmy Microsoft, powyższe zalecenia nadal mają zastosowanie głównie w przypadku korzystania z usługi Azure AD B2C dla klientów, użytkowników lub obywateli i zezwalania im na korzystanie z preferowanych tożsamości społecznościowych, przedsiębiorstw lub lokalnych kont.

Istnieje jednak kilka ważnych różnic. Konfigurowanie usługi Azure AD B2C jako dostawcy tożsamości firmowej w usłudze IAS i konfigurowanie federacji między obiem dzierżawą opisano bardziej szczegółowo w tym wpisie w blogu.

Rejestrowanie aplikacji SAML w usłudze Azure AD B2C

Usługa Azure AD B2C nie ma galerii aplikacji dla przedsiębiorstw, których można użyć do łatwego skonfigurowania relacji zaufania względem dostawcy tożsamości firmowej w usłudze IAS. Zamiast tego należy użyć zasad niestandardowych do zarejestrowania aplikacji SAML w usłudze Azure AD B2C. Ta aplikacja SAML odgrywa tę samą rolę logiczną co aplikacja przedsiębiorstwa w usłudze Microsoft Entra ID, więc te same wskazówki dotyczące przerzucania certyfikatów SAML mają zastosowanie na przykład.

Autoryzacja za pomocą usługi Azure AD B2C

Usługa Azure AD B2C nie obsługuje natywnie używania grup do tworzenia kolekcji użytkowników, do których można przypisać dostęp, co oznacza, że wskazówki dotyczące używania grup Firmy Microsoft Entra do autoryzacji za pośrednictwem kolekcji ról w usłudze BTP muszą być implementowane inaczej.

Na szczęście usługa Azure AD B2C jest wysoce dostosowywalna, dzięki czemu można skonfigurować tokeny SAML wysyłane do usługi IAS w celu uwzględnienia dowolnych informacji niestandardowych. Aby zapoznać się z różnymi opcjami obsługi oświadczeń autoryzacji, zapoznaj się z dokumentacją dołączoną do przykładu Role aplikacji usługi Azure AD B2C, ale podsumowując: za pomocą mechanizmu rozszerzalności łącznika interfejsu API można opcjonalnie nadal używać grup, ról aplikacji, a nawet niestandardowej bazy danych, aby określić, do czego użytkownik może uzyskać dostęp.

Niezależnie od tego, skąd pochodzą informacje o autoryzacji, można je następnie emitować jako Groups atrybut w tokenie SAML, konfigurując tę nazwę atrybutu jako domyślny typ oświadczenia partnera w schemacie oświadczeń lub przez zastąpienie typu oświadczenia partnera w oświadczeniach wyjściowych. Należy jednak pamiętać , że protokół BTP umożliwia mapowania kolekcji ról na atrybuty użytkownika, co oznacza, że dowolna nazwa atrybutu może służyć do podejmowania decyzji dotyczących autoryzacji, nawet jeśli nie używasz nazwy atrybutu Groups .

Następne kroki