अलग-अलग पहचान सिस्टम सिंक करना

Google Cloud Search में ऐक्सेस कंट्रोल, उपयोगकर्ता के Google खाते पर आधारित होता है. कॉन्टेंट को इंडेक्स करते समय, सभी आइटम की एसीएल, मान्य Google उपयोगकर्ता या ग्रुप आईडी (ईमेल पते) के तौर पर हल होनी चाहिए.

कई मामलों में, किसी रिपॉज़िटरी को Google खातों के बारे में सीधे तौर पर जानकारी नहीं होती है. इसके बजाय, लोकल खाते उपयोगकर्ताओं के लिए होते हैं या उपयोगकर्ता, पहचान देने वाली कंपनी के साथ फ़ेडरेटेड साइन-इन का इस्तेमाल करते हैं. ईमेल पते के अलावा, इस पहचान को संगठन से बाहर का आईडी कहा जाता है.

Admin console का इस्तेमाल करके बनाए गए पहचान के सोर्स, पहचान के सिस्टम के बीच के अंतर को कम करते हैं. इसके लिए, ये काम किए जाते हैं:

पहचान के सोर्स का इस्तेमाल तब करें, जब:

  • रिपॉज़िटरी को Google Workspace या Google Cloud Directory में मौजूद उपयोगकर्ता के प्राइमरी ईमेल पते के बारे में जानकारी नहीं है.
  • डेटाबेस में ऐसे ऐक्सेस कंट्रोल ग्रुप तय किए गए हैं जो Google Workspace में ईमेल पते के आधार पर बनाए गए ग्रुप से मेल नहीं खाते.

आइडेंटिटी सोर्स, इंडेक्सिंग को आइडेंटिटी मैपिंग से अलग करके, बेहतर तरीके से काम करते हैं. इससे, एएलसी बनाते समय और आइटम इंडेक्स करते समय, उपयोगकर्ता की जानकारी को बाद में देखने की सुविधा मिलती है.

डिप्लॉयमेंट का उदाहरण

पहले फ़िगर में, एक एंटरप्राइज़ को ऑन-प्रिमाइसेस और क्लाउड, दोनों तरह की रिपॉज़िटरी का इस्तेमाल करते हुए दिखाया गया है. इनमें से हर एक, अलग-अलग तरह के बाहरी आईडी का इस्तेमाल करता है.

अलग-अलग तरह की पहचान के साथ एंटरप्राइज़ डिप्लॉयमेंट का उदाहरण
पहली इमेज. अलग-अलग तरह की पहचान के साथ एंटरप्राइज़ डिप्लॉयमेंट का उदाहरण.

पहली रिपॉज़िटरी, एसएएमएल का इस्तेमाल करके उपयोगकर्ताओं की पहचान उनके ईमेल पते से करती है. इसे Google Workspace या Cloud Directory में मौजूद मुख्य ईमेल पते के बारे में पता होता है. इसलिए, इसे पहचान के स्रोत की ज़रूरत नहीं होती.

Repository 2, ऑन-प्रिमाइसेस डायरेक्ट्री के साथ इंटिग्रेट होती है और उपयोगकर्ताओं की पहचान sAMAccountName के हिसाब से करती है. इस एट्रिब्यूट का इस्तेमाल बाहरी आईडी के तौर पर किया जाता है. इसलिए, इसके लिए पहचान के सोर्स की ज़रूरत होती है.

पहचान स्रोत बनाना

अगर आपको आइडेंटिटी सोर्स की ज़रूरत है, तो Cloud Search में उपयोगकर्ता की पहचान मैप करना लेख पढ़ें.

कॉन्टेंट कनेक्टर बनाने से पहले, आइडेंटिटी सोर्स बनाएं. आपको एसीएल बनाने और डेटा को इंडेक्स करने के लिए, इसके आईडी की ज़रूरत होगी. पहचान का सोर्स बनाने पर, Cloud Directory में एक कस्टम उपयोगकर्ता प्रॉपर्टी भी बन जाती है. इसका इस्तेमाल बाहरी आईडी को सेव करने के लिए किया जाता है. प्रॉपर्टी के नाम में IDENTITY_SOURCE_ID_identity कन्वेंशन का इस्तेमाल किया गया है.

इस टेबल में पहचान के दो सोर्स दिखाए गए हैं: एक SAM खाते के नामों के लिए और दूसरा उपयोगकर्ता आईडी (यूआईडी) के लिए.

पहचान स्रोत उपयोगकर्ता प्रॉपर्टी बाहरी आईडी
id1 id1_identity sAMAccountName
id2 id2_identity uid

अपने एंटरप्राइज़ में इस्तेमाल किए गए हर तरह के बाहरी आईडी के लिए, आइडेंटिटी सोर्स बनाएं.

इस टेबल में दिखाया गया है कि Google खाते और दो बाहरी आईडी वाला उपयोगकर्ता, Cloud Directory में कैसा दिखता है:

उपयोगकर्ता ईमेल id1_identity id2_identity
आरती ann@example.com example\ann 1001

इंडेक्सिंग के लिए एसीएल बनाते समय, इनमें से किसी भी आईडी का इस्तेमाल करके एक ही उपयोगकर्ता का रेफ़रंस दिया जा सकता है.

उपयोगकर्ता एसीएल लिखना

बाहरी आईडी का इस्तेमाल करके प्रिंसिपल बनाने के लिए, getUserPrincipal() या getGroupPrincipal() का इस्तेमाल करें.

इस उदाहरण में, फ़ाइल की अनुमतियां वापस पाई जाती हैं. इसमें वे उपयोगकर्ता भी शामिल हैं जिनके पास फ़ाइल का ऐक्सेस है:

FilePermissionSample.java
/**
 * 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
// 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
// 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);
}

रीडर और मालिक तय करने के बाद, एसीएल बनाएं:

FilePermissionSample.java
// 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();

REST API, identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID पैटर्न का इस्तेमाल करता है. ऐन का id1_identity बदलकर identitysources/id1_identity/users/example/ann हो जाता है. यह उपयोगकर्ता का इंटरमीडिएट आईडी है.

रिपॉज़िटरी के लिए ACL मॉडल बनाने के बारे में ज़्यादा जानने के लिए, ACL देखें.

मैप ग्रुप

पहचान के सोर्स, एसीएल ग्रुप के लिए नेमस्पेस के तौर पर भी काम करते हैं. इसका इस्तेमाल, सिर्फ़ सुरक्षा या किसी रिपॉज़िटरी के लिए इस्तेमाल किए जाने वाले ग्रुप बनाने और उन्हें मैप करने के लिए करें.

ग्रुप बनाने और सदस्यताएं मैनेज करने के लिए, Cloud Identity Groups API का इस्तेमाल करें. ग्रुप को किसी आइडेंटिटी सोर्स से जोड़ने के लिए, आइडेंटिटी सोर्स के नाम को नेमस्पेस के तौर पर इस्तेमाल करें.

इस स्निपेट से एक ग्रुप बनता है:

CreateGroupCommand.java
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);
}

ग्रुप एसीएल बनाना

बाहरी आईडी वाला ग्रुप प्रिंसिपल बनाने के लिए, getGroupPrincipal() का इस्तेमाल करें. इसके बाद, एसीएल बनाएं:

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

आइडेंटिटी कनेक्टर

जब तक उपयोगकर्ताओं के बाहरी आईडी, Cloud Directory में मौजूद Google आईडी से नहीं जुड़ जाते, तब तक वे खोज के नतीजों में आइटम नहीं देख सकते. यह पक्का करने के लिए, तीन तरीके अपनाए जा सकते हैं:

  • Admin console में जाकर, उपयोगकर्ता प्रोफ़ाइलों को मैन्युअल तरीके से अपडेट करें (सिर्फ़ टेस्टिंग के लिए सुझाव दिया जाता है).
  • Directory API का इस्तेमाल करके मैप आईडी.
  • Identity Connector SDK का इस्तेमाल करके, पहचान कनेक्टर बनाएं.

पहचान कनेक्टर, एंटरप्राइज़ की पहचानों से जुड़े बाहरी आईडी को Google की इंटरनल पहचानों से मैप करते हैं. अगर कोई आइडेंटिटी सोर्स बनाया जाता है, तो आपको एक आइडेंटिटी कनेक्टर भी बनाना होगा.

Google Cloud डायरेक्ट्री सिंक (जीसीडीएस), आइडेंटिटी कनेक्टर का एक उदाहरण है. यह Active Directory से Cloud Directory में उपयोगकर्ता और ग्रुप की जानकारी को मैप करता है.

REST API का इस्तेमाल करके आइडेंटिटी सिंक करना

पहचानों को सिंक करने के लिए, update तरीके का इस्तेमाल करें.

आइडेंटिटी को फिर से मैप करना

किसी आइडेंटिटी को फिर से मैप करने के बाद, आपको आइटम को फिर से इंडेक्स करना होगा, ताकि बदलाव लागू हो सके.

  • उपयोगकर्ता की मैपिंग हटाने या बदलने पर, रीइंडेक्सिंग तक ओरिजनल मैपिंग बनी रहती है.
  • अगर आपने मैप किए गए किसी ग्रुप को मिटा दिया है और उसी groupKey के साथ एक नया ग्रुप बनाया है, तो आपको फिर से इंडेक्स करना होगा. इसके बाद ही, आपको ऐक्सेस मिलेगा.