Kontrola dostępu w Google Cloud Search jest oparta na koncie Google użytkownika. Podczas indeksowania treści wszystkie listy kontroli dostępu dla produktów muszą być zgodne z prawidłowymi identyfikatorami użytkowników lub grup (adresami 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 wykorzystywać do identyfikowania kont logowanie sfederowane z użyciem dostawcy tożsamości i identyfikatora innych niż adres e-mail użytkownika. Jest on nazywany identyfikatorem zewnętrznym.
Utworzone w konsoli administracyjnej źródła tożsamości pomagają wypełnić lukę między systemami tożsamości przez:
- Zdefiniuj niestandardowe pole użytkownika do przechowywania identyfikatorów zewnętrznych. To pole służy do znajdowania identyfikatorów zewnętrznych na koncie Google.
- Zdefiniuj przestrzeń nazw dla grup zabezpieczeń zarządzanych przez repozytorium lub dostawcę tożsamości.
Używaj źródeł tożsamości, gdy:
- Repozytorium nie ma informacji o podstawowym adresie e-mail użytkownika w Google Workspace ani Google Cloud Directory.
- Repozytorium definiuje grupy na potrzeby kontroli dostępu, które nie odpowiadają grupom opartym na adresach e-mail w Google Workspace.
Źródła tożsamości poprawiają efektywność indeksowania, oddzielając indeksowanie od mapowania tożsamości. To odłączenie pozwala opóźnić wyszukiwanie użytkownika podczas tworzenia list kontroli dostępu i indeksowania elementów.
Przykładowe wdrożenie
Rysunek 1 przedstawia przykładowe wdrożenie, w którym organizacja używa zarówno repozytoriów lokalnych, jak i repozytoriów w chmurze. Każde repozytorium używa do odwoływania się do użytkowników innego typu identyfikatorów zewnętrznych.
Repozytorium 1 identyfikuje użytkownika przy użyciu adresu e-mail zarejestrowanego za pomocą SAML. Repozytorium 1 zna podstawowy adres 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 na podstawie atrybutu sAMAccountName
. Jako identyfikator zewnętrzny repozytorium 2 używa atrybutu sAMAccountName
, 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, przeczytaj artykuł 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ż będziesz potrzebować identyfikatora źródła tożsamości do tworzenia list kontroli dostępu i danych indeksu. Jak wspomnieliśmy wcześniej, utworzenie źródła tożsamości powoduje też utworzenie niestandardowej właściwości użytkownika w Cloud Directory. Ta właściwość pozwala rejestrować zewnętrzny identyfikator każdego użytkownika w repozytorium. Właściwość nosi nazwę zgodnie z konwencją IDENTITY_SOURCE_ID_identity
.
W tabeli poniżej znajdziesz 2 źródła tożsamości. Jedno zawiera nazwy kont SAM (sAMAccountName) jako identyfikatory zewnętrzne, a drugie uid jako identyfikatory zewnętrzne.
Ź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 używanego do odwoływania się do użytkownika w Twojej firmie.
W tabeli poniżej pokazujemy, jak użytkownik z kontem Google i 2 identyfikatorami zewnętrznymi (id1_identity i id2_identity) oraz z ich wartościami wyświetlają się w Cloud Directory:
użytkownik | id1_identity | id2_identity | |
---|---|---|---|
Anna | ann@example.com | przykład\anna | 1001 |
Podczas tworzenia list kontroli dostępu do indeksowania do indeksowania możesz odwołać się do tego samego użytkownika, używając trzech różnych identyfikatorów (adres e-mail Google, sAMAccountName i uid).
Zapisywanie list kontroli dostępu użytkowników
Użyj metody getUserPrincpal() lub metody getGroupPrincipal(), aby utworzyć podmioty zabezpieczeń z użyciem podanego identyfikatora zewnętrznego.
Poniższy przykład pokazuje, jak uzyskać uprawnienia do pliku. Obejmują one nazwy wszystkich użytkowników, którzy mają dostęp do pliku.
Ten fragment kodu pokazuje, jak przy użyciu identyfikatora zewnętrznego (externalUserName
) zapisanych w atrybutach utworzyć podmioty zabezpieczeń będące właścicielami.
Na koniec z poniższego fragmentu kodu dowiesz się, jak utworzyć podmioty zabezpieczeń, które odczytują plik.
Gdy masz już listę czytelników i właścicieli, możesz ją utworzyć:
Bazowy interfejs API REST podczas tworzenia podmiotów zabezpieczeń używa wzorca identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
dla identyfikatora. Nawiązując do poprzednich tabel, jeśli utworzysz listę kontroli dostępu (ACL) z identyfikatorem id1_identity
(SAMAccountName) Anny, identyfikator ten będzie wskazywać:
identitysources/id1_identity/users/example/ann
Ten cały identyfikator jest nazywany identyfikatorem pośrednim użytkownika, ponieważ zapewnia most między identyfikatorem zewnętrznym a identyfikatorami Google przechowywanymi w Cloud Directory.
Więcej informacji o modelowaniu list kontroli dostępu używanych w repozytorium znajdziesz w artykule Listy kontroli dostępu.
Grupy map
Źródła tożsamości służą również jako przestrzeń nazw dla grup używanych na listach kontroli dostępu (ACL). Za pomocą tej funkcji przestrzeni nazw możesz tworzyć i mapować grupy, które są używane tylko do celów związanych z bezpieczeństwem lub są lokalne dla repozytorium.
Użyj interfejsu Cloud Identity Groups API do utworzenia grupy i zarządzania członkostwem. 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.
Poniższy fragment kodu pokazuje, jak utworzyć grupę za pomocą interfejsu Cloud Identity Groups API:
Tworzenie grupowej listy kontroli dostępu (ACL)
Aby utworzyć listę kontroli dostępu grupy, użyj metody getGroupPrincipal() i utwórz podmiot zabezpieczeń grupy z podanym identyfikatorem zewnętrznym. Następnie utwórz listę kontroli dostępu (ACL) za pomocą klasy Acl.Builder w następujący sposób:
Oprogramowanie sprzęgające tożsamości
Chociaż do tworzenia list kontroli dostępu i elementów indeksu możesz używać zewnętrznych identyfikatorów niepochodzących od Google, użytkownicy nie będą widzieć elementów w wyszukiwaniu, dopóki ich identyfikatory zewnętrzne nie będą miały identyfikatora Google w Cloud Directory. Są 3 sposoby na to, aby mieć pewność, że Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika:
- Ręczne aktualizowanie poszczególnych profili użytkowników w konsoli administracyjnej Ten proces jest zalecany tylko w przypadku testowania i tworzenia prototypów przy użyciu kilku profili użytkowników.
- Zmapuj zewnętrzne identyfikatory na identyfikatory Google przy użyciu interfejsu Directory API. Ten proces jest zalecany dla osób, które nie mogą korzystać z pakietu Identity Connector SDK.
- Utwórz oprogramowanie sprzęgające tożsamości za pomocą pakietu SDK Identity Connector. Upraszcza on użycie interfejsu Directory API do mapowania identyfikatorów.
Oprogramowanie sprzęgające tożsamości to programy służące do mapowania zewnętrznych identyfikatorów z tożsamości firm (użytkowników i grup) na wewnętrzne tożsamości Google używane przez Google Cloud Search. Jeśli musisz utworzyć źródło tożsamości, musisz utworzyć oprogramowanie sprzęgające tożsamości.
Przykładem łącznika tożsamości jest Google Cloud Directory Sync (GCDS). Oprogramowanie sprzęgające tożsamości mapuje informacje o użytkownikach i grupach z 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 przy użyciu interfejsu API REST
Użyj metody update
, aby zsynchronizować tożsamości za pomocą interfejsu API REST.
Mapowanie tożsamości
Po zmapowaniu tożsamości elementu z inną tożsamością musisz ponownie zindeksować elementy, aby uzyskać dostęp do nowej tożsamości. Na przykład
- Jeśli spróbujesz usunąć mapowanie z konta użytkownika lub ponownie je zmapować, oryginalne mapowanie zostanie zachowane do czasu ponownego zindeksowania.
- Jeśli usuniesz zmapowaną grupę, która znajduje się na liście kontroli dostępu produktu, a następnie utworzysz nową grupę z tym samym identyfikatorem
groupKey
, nowa grupa nie zapewni dostępu do elementu, dopóki ten element nie zostanie ponownie zindeksowany.