Kontrola dostępu w Google Cloud Search zależy od konta Google użytkownika. Podczas indeksowania treści wszystkie listy kontroli dostępu elementów muszą być dopasowane do prawidłowych identyfikatorów użytkowników lub grup (adresów e-mail) Google.
W wielu przypadkach repozytorium nie ma bezpośredniej wiedzy o kontach Google. Zamiast tego użytkownicy mogą być reprezentowani przez konta lokalne lub do identyfikowania poszczególnych kont używać logowania sfederowanego z użyciem dostawcy tożsamości i identyfikatora innego niż adres e-mail użytkownika. Jest to tzw. identyfikator zewnętrzny.
Źródła tożsamości utworzone w konsoli administracyjnej pomagają wypełnić tę lukę między systemami tożsamości przez:
- Utworzenie niestandardowego pola użytkownika do przechowywania zewnętrznych identyfikatorów. To pole służy do przypisywania zewnętrznych identyfikatorów do konta Google.
- Zdefiniuj przestrzeń nazw dla grup zabezpieczeń zarządzaną przez repozytorium lub dostawcę tożsamości.
Użyj źródeł tożsamości, gdy:
- Repozytorium nie zna podstawowego adresu e-mail użytkownika w Google Workspace ani w Google Cloud Directory.
- Repozytorium określa grupy kontroli dostępu, które nie odpowiadają grupom opartym na adresach e-mail w Google Workspace.
Źródła tożsamości poprawiają wydajność indeksowania, ponieważ oddzielają indeksowanie od mapowania tożsamości. Takie rozłączenie umożliwia opóźnienie wyszukiwania użytkownika podczas tworzenia list kontroli dostępu i elementów indeksowania.
Przykładowe wdrożenie
Rysunek 1 przedstawia przykładowe wdrożenie, w którym przedsiębiorstwo używa zarówno repozytoriów lokalnych, jak i w chmurze. Każde repozytorium używa innego typu identyfikatora zewnętrznego do odwołań do użytkowników.
Repozytorium 1 identyfikuje użytkownika na podstawie adresu e-mail zweryfikowanego za pomocą SAML. Repozytorium 1 wie o podstawowym adresie e-mail użytkownika w Google Workspace lub Cloud Directory, więc źródło tożsamości nie jest potrzebne.
Repozytorium 2 integruje się bezpośrednio z katalogiem lokalnym i identyfikuje użytkownika za pomocą atrybutu sAMAccountName
. Repozytorium 2 używa atrybutu sAMAccountName
jako identyfikatora zewnętrznego, więc potrzebne jest źródło tożsamości.
Tworzenie źródła tożsamości
Jeśli potrzebujesz źródła tożsamości, zapoznaj się z artykułem Mapowanie tożsamości użytkowników w Cloud Search.
Przed utworzeniem oprogramowania sprzęgającego treści musisz utworzyć źródło tożsamości, ponieważ identyfikator źródła tożsamości będzie potrzebny do tworzenia list kontroli dostępu i danych indeksu. Jak już wspomnieliśmy, utworzenie źródła tożsamości powoduje też utworzenie niestandardowej właściwości użytkownika w Cloud Directory. Dzięki tej właściwości możesz rejestrować zewnętrzny identyfikator każdego użytkownika w repozytorium. Nazwa właściwości jest zgodna z konwencją IDENTITY_SOURCE_ID_identity
.
W tabeli poniżej znajdziesz 2 źródła tożsamości: jedno do przechowywania nazw kont SAM (sAMAccountName) jako identyfikatorów zewnętrznych, a drugie do przechowywania identyfikatorów użytkowników (uid) jako identyfikatorów zewnętrznych.
Źródło tożsamości | właściwość użytkownika | identyfikator zewnętrzny |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
Utwórz źródło tożsamości dla każdego możliwego identyfikatora zewnętrznego, który służy do odnoszenia się do użytkownika w firmie.
W tabeli poniżej pokazujemy, jak użytkownik mający konto Google i 2 identyfikatory zewnętrzne (id1_identity i id2_identity) wyświetlają się w Cloud Directory:
użytkownik | id1_identity | id2_identity | |
---|---|---|---|
Anna | ann@example.com | przykład\ann | 1001 |
Możesz odwoływać się do tego samego użytkownika za pomocą 3 różnych identyfikatorów (adres e-mail Google, sAMAccountName i uid) podczas tworzenia list kontroli dostępu na potrzeby indeksowania.
Zapisywanie list kontroli dostępu użytkowników
Użyj metody getUserPrincpal() lub getGroupPrincipal(), aby utworzyć podmioty zabezpieczeń z użyciem podanego identyfikatora zewnętrznego.
Przykład poniżej pokazuje, jak pobrać uprawnienia dotyczące pliku. Uprawnienia te obejmują nazwę każdego użytkownika, który ma dostęp do pliku.
Poniższy fragment kodu pokazuje, jak utworzyć podmioty zabezpieczeń, które są właścicielami, za pomocą identyfikatora zewnętrznego (externalUserName
) zapisanego w atrybutach.
Na koniec fragment kodu poniżej pokazuje, jak tworzyć podmioty zabezpieczeń, które będą czytać plik.
Gdy masz już listę czytelników i właścicieli, możesz utworzyć listę kontroli dostępu:
Podczas tworzenia podmiotów zabezpieczeń podstawowy interfejs API REST używa wzorca identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
dla identyfikatora. Jeśli utworzysz listę kontroli dostępu (ACL) z użyciem parametru id1_identity
Anny (SAMAccountName), identyfikator będzie wskazywał poprzednie tabele:
identitysources/id1_identity/users/example/ann
Ten identyfikator jest nazywany identyfikatorem pośrednim użytkownika, ponieważ stanowi most między identyfikatorem zewnętrznym a identyfikatorami Google przechowywanymi w Cloud Directory.
Więcej informacji na temat modelowania list kontroli dostępu używanych na potrzeby repozytorium znajdziesz w artykule Listy kontroli dostępu.
Grupy map
Źródła tożsamości służą też jako przestrzeń nazw dla grup używanych na listach kontroli dostępu. Tej funkcji przestrzeni nazw możesz użyć do tworzenia i mapowania grup, które są używane tylko do celów związanych z bezpieczeństwem lub są dostępne lokalnie w repozytorium.
Aby utworzyć grupę i zarządzać członkostwem, użyj interfejsu Cloud Identity Groups API. Aby powiązać grupę ze źródłem tożsamości, użyj nazwy zasobu źródła tożsamości jako przestrzeni nazw grupy.
Ten fragment kodu pokazuje, jak utworzyć grupę przy użyciu interfejsu Cloud Identity Groups API:
Utwórz listę ACL grupy
Aby utworzyć listę kontroli dostępu grupy, użyj metody getGroupPrincipal() w celu utworzenia podmiotu zabezpieczeń grupy przy użyciu podanego identyfikatora zewnętrznego. Następnie za pomocą klasy Acl.Builder utwórz listę kontroli dostępu w następujący sposób:
Oprogramowanie sprzęgające tożsamości
Mimo że do tworzenia list kontroli dostępu i elementów indeksowania możesz używać zewnętrznych identyfikatorów spoza Google, użytkownicy nie widzą elementów w wynikach wyszukiwania, dopóki ich zewnętrzne identyfikatory nie zostaną dopasowane do identyfikatora Google w Cloud Directory. Istnieją 3 sposoby, aby sprawdzić, czy Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika:
- Ręcznie zaktualizuj każdy profil każdego użytkownika w konsoli administracyjnej. Ten proces jest zalecany tylko w przypadku testowania i prototypowania profili użytkowników z wykorzystaniem kilku profili użytkowników.
- Zmapuj identyfikatory zewnętrzne na identyfikatory Google za pomocą interfejsu Directory API. Ten proces jest zalecany dla osób, które nie mogą korzystać z pakietu SDK Identity Connector.
- Utwórz oprogramowanie sprzęgające tożsamości za pomocą pakietu SDK Identity Connector. Ten pakiet SDK upraszcza korzystanie z interfejsu Directory API do mapowania identyfikatorów.
Oprogramowanie sprzęgające tożsamości to programy używane do mapowania zewnętrznych identyfikatorów z tożsamości firmowych (użytkowników i grup) na wewnętrzne tożsamości Google używane przez Google Cloud Search. Jeśli chcesz utworzyć źródło tożsamości, musisz utworzyć łącznik tożsamości.
Przykładem oprogramowania sprzęgającego tożsamości jest Google Cloud Directory Sync (GCDS). To oprogramowanie sprzęgające tożsamości mapuje informacje o użytkownikach i grupach z usługi Active Directory firmy Microsoft do Cloud Directory wraz z atrybutami użytkowników, które mogą reprezentować ich tożsamość w innych systemach.
Zsynchronizuj tożsamości za pomocą interfejsu API REST
Aby zsynchronizować tożsamości za pomocą interfejsu API REST, użyj metody update
.
Mapowanie tożsamości
Po zmapowaniu tożsamości elementu na inną tożsamość musisz ponownie zindeksować elementy, aby uwzględnić nową tożsamość. Przykład:
- jeśli spróbujesz usunąć mapowanie z użytkownika lub ponownie zmapować je na innego użytkownika, pierwotne mapowanie pozostanie zachowywane do momentu ponownego zindeksowania.
- Jeśli usuniesz zmapowaną grupę, która znajduje się na liście kontroli dostępu elementów, a następnie utworzysz nową grupę z takim samym atrybutem
groupKey
, nowa grupa nie udostępni elementu, dopóki nie zostanie ponownie zindeksowany.