סנכרון של מערכות זהות שונות

בקרת הגישה ב-Google Cloud Search מבוססת על חשבון Google של המשתמש. כשמוסיפים תוכן לאינדקס, כל רשימות ה-ACL של הפריטים חייבות להתאים למשתמש Google חוקי או מזהי קבוצות (כתובות אימייל).

במקרים רבים למאגר אין ידע ישיר על Google חשבונות. במקום זאת, יכול להיות שהמשתמשים מיוצגים על ידי חשבונות מקומיים או כניסה מאוחדת עם מזהה וספק זהויות, מאשר כתובת האימייל של המשתמש, כדי לזהות כל חשבון. המזהה הזה נקרא מזהה חיצוני.

מקורות של זהויות שנוצרו באמצעות מסוף Admin עוזרים לגשר על הפער הזה על ידי:

• הגדרת שדה משתמש מותאם אישית כדי לאחסן מזהים חיצוניים. השדה הזה משמש לזיהוי מזהים חיצוניים ל-Google חשבון.
• הגדרת מרחב שמות לקבוצות אבטחה מנוהלות על ידי מאגר ספק זהויות.

יש להשתמש במקורות זהות כאשר:

• המאגר לא יודע מה כתובת האימייל הראשית של המשתמש ב-Google Workspace או ב-Google Cloud Directory.
• במאגר מוגדרות קבוצות של בקרת גישה שלא תואמות לקבוצות מבוססות-אימייל ב-Google Workspace.

מקורות זהויות משפרים את יעילות ההוספה לאינדקס על ידי הפרדתם מאינדקס ממיפוי זהויות. ההצמדה הזו מאפשרת לדחות חיפוש של נתוני המשתמש במהלך יצירת רשימות ACL והוספה לאינדקס של פריטים.

פריסה לדוגמה

איור 1 מציג פריסה לדוגמה שבה גם בארגון וגם בענן מאגרים משמשים ארגון. כל מאגר משתמש בסוג אחר של מזהה חיצוני כדי להפנות למשתמשים.

איור 1. דוגמה לפריסה ארגונית עם סוגי הזהות שונים.

מאגר 1 מזהה את המשתמש באמצעות כתובת האימייל שצוינה באמצעות SAML. כי למאגר הראשון יש מידע על כתובת האימייל הראשית של המשתמש ב- לא צריך מקור זהות, ב-Google Workspace או ב-Cloud Directory.

Repository 2 משתלב ישירות עם ספרייה מקומית מזהה את המשתמש לפי המאפיין sAMAccountName. כי מאגר 2 משתמש במאפיין sAMAccountName בתור מזהה חיצוני, מקור הזהות הדרושים.

יצירת מקור זהויות

אם אתם צריכים מקור זהות, תוכלו לקרוא את המאמר מיפוי של זהויות משתמשים ב-Cloud Search.

עליך ליצור מקור זהות לפני יצירת מחבר תוכן כי יש צורך במזהה של מקור הזהויות כדי ליצור רשימות ACL ונתוני אינדקס. כפי שצוין קודם לכן, יצירת מקור זהות יוצרת גם מאפיין משתמש מותאם אישית ב-Cloud Directory. צריך להשתמש בנכס הזה כדי לתעד את המזהה החיצוני של כל במאגר שלכם. השם של הנכס צריך לכלול את מוסכמות: IDENTITY_SOURCE_ID_identity.

בטבלה הבאה מוצגים שני מקורות זהות, אחד לאחסון השמות של חשבונות SAM (sAMAccountName) כמזהים חיצוניים ואחד לשמירת מזהי המשתמשים (uid) כמזהים חיצוניים.

מקור הזהות	מאפיין משתמש	מזהה חיצוני
id1	id1_identity	sAMAccountName
id2	id2_identity	Uid

ליצור מקור זהות לכל מזהה חיצוני אפשרי שמשמש יפנו למשתמש בארגון

בטבלה הבאה מוצג האופן שבו משתמש עם חשבון Google ושני מזהים חיצוניים (id1_identity ו-id2_identity) והערכים שלהם מופיעים ב-Cloud Directory:

משתמש	אימייל	id1_identity	id2_identity
רות	[e-mail]	example\ann	1001

תוכלו להפנות לאותו משתמש באמצעות שלושת המזהים השונים, (כתובת אימייל של Google, sAMAccountName ו-uid) כשיוצרים רשימות ACL להוספה לאינדקס.

כתיבת רשימות ACL של משתמשים

משתמשים ב getUserPrincpal() או getGroupPrincipal() כדי ליצור חשבונות משתמשים באמצעות מזהה חיצוני נתון.

תוכלו להיעזר בדוגמה הבאה כדי לאחזר הרשאות לקובץ. האלה ההרשאות כוללות את השם של כל משתמש שיש לו גישה לקובץ.

FilePermissionSample.java

הצגת הקוד ב-GitHub

/**
 * Sample for mapping permissions from a source repository to Cloud Search
 * ACLs. In this example, POSIX file permissions are used a the source
 * permissions.
 *
 * @return Acl
 * @throws IOException if unable to read file permissions
 */
static Acl mapPosixFilePermissionToCloudSearchAcl(Path pathToFile) throws IOException {
  // Id of the identity source for external user/group IDs. Shown here,
  // but may be omitted in the SDK as it is automatically applied
  // based on the `api.identitySourceId` configuration parameter.
  String identitySourceId = "abcdef12345";

  // Retrieve the file system permissions for the item being indexed.
  PosixFileAttributeView attributeView = Files.getFileAttributeView(
      pathToFile,
      PosixFileAttributeView.class,
      LinkOption.NOFOLLOW_LINKS);

  if (attributeView == null) {
    // Can't read, return empty ACl
    return new Acl.Builder().build();
  }

  PosixFileAttributes attrs = attributeView.readAttributes();
  // ...
}

קטע הקוד הבא מראה איך ליצור חשבונות משתמשים שהם בעלים באמצעות המזהה החיצוני (externalUserName) ששמור במאפיינים.

FilePermissionSample.java

הצגת הקוד ב-GitHub

// Owner, for search quality.
// Note that for principals the name is not the primary
// email address in Cloud Directory, but the local ID defined
// by the OS. Users and groups must be referred to by their
// external ID and mapped via an identity source.
List<Principal> owners = Collections.singletonList(
    Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId)
);

לבסוף, קטע הקוד הבא מראה איך ליצור חשבונות משתמשים קוראים של הקובץ.

FilePermissionSample.java

הצגת הקוד ב-GitHub

// List of users to grant access to
List<Principal> readers = new ArrayList<>();

// Add owner, group, others to readers list if permissions
// exist. For this example, other is mapped to everyone
// in the organization.
Set<PosixFilePermission> permissions = attrs.permissions();
if (permissions.contains(PosixFilePermission.OWNER_READ)) {
  readers.add(Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId));
}
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}
if (permissions.contains(PosixFilePermission.OTHERS_READ)) {
  Principal everyone = Acl.getCustomerPrincipal();
  readers.add(everyone);
}

אחרי שיוצרים רשימת קוראים ובעלים, אפשר ליצור את ה-ACL:

FilePermissionSample.java

הצגת הקוד ב-GitHub

// Build the Cloud Search ACL. Note that inheritance of permissions
// from parents is omitted. See `setInheritFrom()` and `setInheritanceType()`
// methods on the builder if required by your implementation.
Acl acl = new Acl.Builder()
    .setReaders(readers)
    .setOwners(owners)
    .build();

ב-API ל-REST נעשה שימוש בדפוס הזה identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID את המזהה כשיוצרים חשבונות משתמשים. נחזור לטבלאות הקודמות. אם תיצרו רשימת ACL עם id1_identity של אן (SAMAccountName), המזהה צריך להפוך ל:

identitysources/id1_identity/users/example/ann

המזהה המלא הזה נקרא מזהה הביניים של המשתמש כי הוא מספק גשר בין המזהה החיצוני למזהי Google שמאוחסנים ב-Cloud Directory.

למידע נוסף על בניית מודלים של רשימות ACL שמשמשות למאגר, ראו: רשימות ACL.

מיפוי קבוצות

מקורות של זהויות משמשים גם כמרחב שמות לקבוצות שנמצאות בשימוש ברשימות ACL. אפשר להשתמש במרחב השמות הזה כדי ליצור קבוצות שמשמשות לאבטחה ולמפות אותן למטרות בלבד או באופן מקומי למאגר.

שימוש ב-Cloud Identity Groups API כדי ליצור קבוצה ולנהל את החברים בה. כדי לשייך את הקבוצה אל מקור זהויות, צריך להשתמש בשם המשאב של מקור הזהויות בתור מרחב השמות של הקבוצה.

קטע הקוד הבא מראה איך ליצור קבוצה באמצעות Cloud Identity Groups API:

CreateGroupCommand.java

הצגת הקוד ב-GitHub

String namespace = "identitysources/" + idSource;
Group group = new Group()
    .setGroupKey(new EntityKey().setNamespace(namespace).setId(groupId))
    .setDescription("Demo group")
    .setDisplayName(groupName)
    .setLabels(Collections.singletonMap("system/groups/external", ""))
    .setParent(namespace);
try {
  CloudIdentity service = Utils.buildCloudIdentityService();
  Operation createOperation = service.groups().create(group).execute();

  if (createOperation.getDone()) {
    // Note: The response contains the data for a Group object, but as
    // individual fields. To convert to a Group instance, either populate
    // the fields individually or serialize & deserialize to/from JSON.
    //
    // Example:
    // String json = service.getJsonFactory().toString(response);
    // Group createdGroup =  service.getObjectParser()
    //     .parseAndClose(new StringReader(json), Group.class);
    System.out.printf("Group: %s\n",
        createOperation.getResponse().toString());
  } else {
    // Handle case where operation not yet complete, poll for
    // completion. API is currently synchronous and all operations return
    // as completed.
    // ...
  }
} catch (Exception e) {
  System.err.printf("Unable to create group: %s", e.getMessage());
  e.printStackTrace(System.err);
}

יצירת רשימת ACL קבוצתית

כדי ליצור רשימת ACL קבוצתית, משתמשים ב getGroupPrincipal() כדי ליצור חשבון משתמש קבוצתי באמצעות מזהה חיצוני נתון. לאחר מכן, יוצרים ACL באמצעות Acl.Builder הכיתה באופן הבא:

FilePermissionSample.java

הצגת הקוד ב-GitHub

if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

מחברי זהויות

אפשר להשתמש במזהים חיצוניים שאינם של Google כדי ליצור רשימות ACL ופריטים לאינדקס, משתמשים לא יוכלו לראות פריטים בחיפוש עד שהמזהים החיצוניים שלהם יפנו ל-Google מזהה ב-Cloud Directory. יש שלוש דרכים להבטיח ספריית Cloud יודעת גם את המזהה ב-Google וגם את המזהים החיצוניים של המשתמש:

• לעדכן ידנית כל פרופיל משתמש בנפרד דרך מסוף Admin התהליך הזה מומלץ רק לצורך בדיקה ויצירת אב טיפוס באמצעות מספר קטן של פרופילי משתמשים.
• מיפוי מזהים חיצוניים למזהים של Google באמצעות Directory API. התהליך הזה מומלץ למי שלא יכול להשתמש ב-SDK של מחבר הזהויות.
• יצירת מחבר זהויות באמצעות SDK של מחבר זהויות. ערכת ה-SDK הזו מפשטת את השימוש ב-Directory API למיפוי מזהים.

מחברי זהויות הם תוכנות שמשמשות למיפוי של מזהים חיצוניים מארגונים זהויות (משתמשים וקבוצות) לזהויות הפנימיות של Google שמשמשות את Google ב-Cloud Search. אם אתם חייבים ליצור מקור זהות, יוצרים מחבר זהויות.

Google Cloud Directory Sync (GCDS) הוא דוגמה למחבר זהויות. מחבר הזהויות הזה ממפה את המשתמשים ואת לקבץ מידע מ-Active Directory של Microsoft ל-Cloud Directory עם מאפייני המשתמש שעשויים לייצג את הזהות שלו במערכות אחרות.

סנכרון זהויות באמצעות API ל-REST

משתמשים בשיטה update כדי לסנכרן זהויות באמצעות API ל-REST.

מיפוי מחדש של זהויות

אחרי מיפוי מחדש של זהות פריט לזהות אחרת, צריך להוסיף פריטים לאינדקס מחדש. הזהות החדשה תישמר. לדוגמה,

• אם מנסים להסיר מיפוי ממשתמש או למפות אותו מחדש למשתמש אחר, המיפוי המקורי עדיין יישמר עד ליצירת האינדקס מחדש.
• אם מוחקים קבוצה ממופה שנמצאת ברשימת ACL של פריט, ולאחר מכן יוצרים קבוצה חדשה עם אותו groupKey, לקבוצה החדשה אין גישה עד שהפריט יתווסף מחדש לאינדקס.