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

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

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

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

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

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

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

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

פריסה לדוגמה

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

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

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

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

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

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

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

בטבלה הבאה מוצגים שני מקורות זהות: אחד שמכיל שמות של חשבונות SAM (sAMAccountName) כמזהים חיצוניים והשני לשמירת מזהי User-ID (uid) כמזהים חיצוניים.

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

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

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

user	אימייל	id1_identity	id2_identity
רות	[e-mail]	דוגמה\ann	1001

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

כתיבה של רשימות 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 Directory יודע את מזהה Google וגם את המזהים החיצוניים של משתמש:

• עדכון ידני של כל פרופיל משתמש באמצעות מסוף Admin התהליך הזה מומלץ רק לבדיקה ויצירת אב טיפוס באמצעות כמה פרופילי משתמשים.
• מיפוי מזהים חיצוניים למזהים של Google באמצעות Directory API. התהליך הזה מומלץ למי שלא יכול להשתמש ב-Identity Connector SDK.
• יוצרים מחבר זהות באמצעות Identity Connector 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, הקבוצה החדשה לא תספק גישה לפריט עד שהפריט יתווסף מחדש לאינדקס.