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

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

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

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

• बाहरी आईडी को स्टोर करने के लिए, कस्टम उपयोगकर्ता फ़ील्ड तय करना. इस फ़ील्ड का इस्तेमाल, किसी Google खाते के लिए बाहरी आईडी को हल करने के लिए किया जाता है.
• सुरक्षा ग्रुप के लिए नेमस्पेस तय करें. इसे किसी रिपॉज़िटरी या आइडेंटिटी प्रोवाइडर मैनेज करता है.

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

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

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

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

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

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

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

आइडेंटिटी सोर्स बनाना

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

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

नीचे दी गई टेबल में, आइडेंटिटी के दो सोर्स दिखाए गए हैं. पहला, बाहरी आईडी के तौर पर एसएएम खाते के नाम (sAMAccountName) को सेव करने के लिए और दूसरा, बाहरी आईडी के तौर पर यूज़र आईडी (uid) को सेव करने के लिए.

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

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

इंडेक्स करने के लिए ACL बनाते समय, तीन अलग-अलग आईडी (Google ईमेल, sAMAccountName, और uid) का इस्तेमाल करके, एक ही उपयोगकर्ता का रेफ़रंस दिया जा सकता है.

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

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

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

/**
 * 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) का इस्तेमाल करके, ऐसे प्रिंसिपल बनाने का तरीका बताया गया है जो मालिक हैं.

// 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)
);

आखिर में, नीचे दिए गए कोड स्निपेट में, फ़ाइल के पाठक के तौर पर प्रिंसिपल बनाने का तरीका बताया गया है.

// 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);
}

पाठकों और मालिकों की सूची तैयार करने के बाद, एसीएल बनाया जा सकता है:

// 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 (SAMAccountName) के साथ एक एसीएल बनाया है, तो आईडी इस तरह दिखेगा:

identitysources/id1_identity/users/example/ann

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

किसी रिपॉज़िटरी के लिए इस्तेमाल किए जाने वाले एसीएल को मॉडलिंग करने के बारे में ज़्यादा जानकारी के लिए, एसीएल देखें.

मैप ग्रुप

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

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

यहां दिए गए कोड स्निपेट में, Cloud Identity Groups API का इस्तेमाल करके ग्रुप बनाने का तरीका बताया गया है:

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 बनाने के लिए, दिए गए बाहरी आईडी का इस्तेमाल करके ग्रुप प्रिंसिपल बनाने के लिए, getGroupPrincipal() तरीके का इस्तेमाल करें. इसके बाद, Acl.Builder क्लास का इस्तेमाल करके, इस तरह से ACL बनाएं:

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

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

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

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

आइडेंटिटी कनेक्टर ऐसे प्रोग्राम होते हैं जिनका इस्तेमाल, एंटरप्राइज़ आइडेंटिटी (उपयोगकर्ता और ग्रुप) से बाहरी आईडी को Google Cloud Search में इस्तेमाल होने वाली Google की आंतरिक आइडेंटिटी से मैप करने के लिए किया जाता है. अगर आपको कोई आइडेंटिटी सोर्स बनाना है, तो आपको आइडेंटिटी कनेक्टर बनाना होगा.

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

REST API का इस्तेमाल करके पहचानों को सिंक करना

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

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

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

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