Kontrola dostępu w Google Cloud Search jest oparta na koncie Google użytkownika. Podczas indeksowania treści wszystkie listy kontroli dostępu dla elementów muszą być przypisane do prawidłowego użytkownika Google lub identyfikatorów grup (adresów e-mail).
W wielu przypadkach repozytorium nie dysponuje bezpośrednią wiedzą o Google, kont. Zamiast tego użytkownicy mogą być reprezentowani przez konta lokalne lub używać atrybutu logowanie sfederowane z użyciem dostawcy tożsamości i identyfikatora, inne niż adres e-mail użytkownika, aby zidentyfikować każde z nich. Jest to tzw. identyfikator identyfikator zewnętrzny.
Utworzone za pomocą konsoli administracyjnej źródła tożsamości pomagają wypełnić lukę systemów tożsamości:
- Zdefiniuj niestandardowe pole użytkownika do przechowywania identyfikatorów zewnętrznych. To pole służy do przekazywania identyfikatorów zewnętrznych do identyfikatora Google. koncie.
- Zdefiniuj przestrzeń nazw dla grup zabezpieczeń. zarządzane 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żytkownik w Google Workspace lub Google Cloud Directory.
- Repozytorium definiuje grupy na potrzeby kontroli dostępu, które nie odpowiadają do grup opartych na e-mailach w Google Workspace.
Źródła tożsamości poprawiają efektywność indeksowania dzięki rozłączeniu indeksowania z 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
Ilustracja 1 przedstawia przykładowe wdrożenie, w którym zarówno lokalnie, jak i w chmurze Repozytoria są używane przez firmę. Każde repozytorium używa innego typu zewnętrznego identyfikatora, aby odwołać się do użytkowników.
![Przykładowe wdrożenie](https://google-developers.gonglchuangl.net/static/cloud-search/images/identity-arch.png?authuser=1&hl=pl)
Repozytorium 1 identyfikuje użytkownika na podstawie adresu e-mail zarejestrowanego za pomocą SAML. Ponieważ repozytorium 1 zna podstawowy adres e-mail użytkownika w Google Workspace lub Cloud Directory, ź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
. Ponieważ repozytorium 2
Używa atrybutu sAMAccountName
jako identyfikatora zewnętrznego, a źródłem tożsamości jest
niezbędną.
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ż
potrzebujesz identyfikatora źródła tożsamości do tworzenia list kontroli dostępu i danych indeksowania. Jak wspomniano
wcześniej utworzenie źródła tożsamości powoduje też utworzenie
niestandardowa właściwość użytkownika
w Cloud Directory. Użyj tej usługi, aby zarejestrować identyfikator zewnętrzny dla każdego
użytkownika w repozytorium. Nazwa właściwości pojawia się za pomocą atrybutu
IDENTITY_SOURCE_ID_identity
.
Tabela poniżej zawiera 2 źródła tożsamości, w tym jedno z nazwami kont SAM (sAMAccountName) jako identyfikatory zewnętrzne, a drugi 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 jest używany do odnosi 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 oraz id2_identity) i ich wartości pojawiają się w Cloud Directory:
użytkownik | id1_identity | id2_identity | |
---|---|---|---|
Anna | ann@example.com | przykład\anna | 1001 |
Możesz odwołać się do tego samego użytkownika, używając 3 różnych identyfikatorów: (Adres e-mail Google, sAMAccountName i Uid) podczas tworzenia list kontroli dostępu do indeksowania.
Zapisywanie list kontroli dostępu użytkowników
Użyj getUserPrincpal() lub getGroupPrincipal() do tworzenia podmiotów zabezpieczeń przy użyciu podanego identyfikatora zewnętrznego.
Poniższy przykład pokazuje, jak uzyskać uprawnienia do pliku. Te uprawnienia obejmują nazwę każdego użytkownika, który ma dostęp do pliku.
Ten fragment kodu pokazuje, jak utworzyć podmioty zabezpieczeń, które są właścicielami
z użyciem identyfikatora zewnętrznego (externalUserName
) zapisanego w atrybutach.
Na koniec ten fragment kodu pokazuje, jak utworzyć podmioty zabezpieczeń, które czytelnicy pliku.
Gdy masz już listę czytelników i właścicieli, możesz ją utworzyć:
Podstawowy interfejs API REST używa wzorca
identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
dla identyfikatora przy tworzeniu podmiotów zabezpieczeń. W nawiązaniu do poprzednich tabel
jeśli utworzysz listę ACL o nazwie id1_identity
(SAMAccountName) Anny, identyfikator ten będzie
ustaw jako:
identitysources/id1_identity/users/example/ann
Cały identyfikator jest nazywany identyfikatorem pośrednim użytkownika. ponieważ stanowi pomost między identyfikatorem zewnętrznym a identyfikatorami Google zapisanymi w pamięci podręcznej. dzięki Cloud Directory.
Więcej informacji na temat modelowania list kontroli dostępu używanych przez 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). Dostępne opcje użyj tej funkcji przestrzeni nazw do tworzenia i mapowania grup plików wykorzystywanych w celu zapewnienia bezpieczeństwa służą tylko do celów lub są lokalne dla repozytorium.
Użycie interfejsu Cloud Identity Groups API aby utworzyć grupę i zarządzać członkostwem. Aby powiązać grupę z źródła tożsamości, użyj nazwy zasobu źródła tożsamości jako przestrzeni nazw grupy.
Fragment kodu poniżej pokazuje, jak utworzyć grupę za pomocą atrybutu Cloud Identity Groups API:
Tworzenie grupowej listy kontroli dostępu (ACL)
Aby utworzyć listę kontroli dostępu grupy, użyj getGroupPrincipal() do utworzenia podmiotu zabezpieczeń grupy przy użyciu podanego identyfikatora zewnętrznego. Następnie utwórz Lista ACL wykorzystująca Acl.Builder klasy w następujący sposób:
Oprogramowanie sprzęgające tożsamości
Do tworzenia list kontroli dostępu i indeksowania elementów można używać zewnętrznych identyfikatorów (niepochodzących od Google), użytkownicy nie widzą elementów w wyszukiwaniu, dopóki ich identyfikatory zewnętrzne nie będą miały identyfikatorów Google Identyfikator w Cloud Directory. Są 3 sposoby, aby zapewnić Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika:
- ręcznie aktualizować poszczególne profile użytkowników w konsoli administracyjnej, Ten proces jest zalecany do 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.
- Tworzenie oprogramowania sprzęgającego tożsamości za pomocą Identity Connector SDK. Upraszcza on użycie interfejsu Directory API do mapowania identyfikatorów.
Oprogramowanie sprzęgające tożsamości to programy używane do mapowania zewnętrznych identyfikatorów firm tożsamości (użytkowników i grup) a wewnętrznymi tożsamościami Google używanymi przez Google, Cloud Search. Jeśli musisz utworzyć źródło tożsamości, musisz utworzyć oprogramowanie sprzęgające tożsamości.
Google Cloud Directory Sync (GCDS) to Przykład łącznika tożsamości. To oprogramowanie sprzęgające tożsamości mapuje użytkowników i grupować informacje z Active Directory firmy Microsoft do Cloud Directory z atrybutami użytkownika, które mogą reprezentować jego 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 przejęła ona nową tożsamość. Na przykład
- jeśli spróbujesz usunąć mapowanie z konta użytkownika lub ponownie je zmapować, oryginalne mapowanie jest zachowywane do czasu jego ponownego zindeksowania.
- Jeśli usuniesz zmapowaną grupę, która znajduje się na liście kontroli dostępu elementu, a następnie utworzysz
nowej grupy z tą samą wartością
groupKey
, nowa grupa nie zapewnia dostępu do do czasu jego ponownego zindeksowania.