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

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

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

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

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

इनमें से किसी भी स्थिति में पहचान के सोर्स का इस्तेमाल करें:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

identitysources/id1_identity/users/example/ann

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

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

ग्रुप मैप करना

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

ग्रुप बनाने और सदस्यताओं को मैनेज करने के लिए, 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);
}

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

ग्रुप एसीएल बनाने के लिए, 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 का इस्तेमाल करके, पहचान कनेक्टर बनाएं. यह एसडीके, आईडी को मैप करने के लिए Directory API का इस्तेमाल करना आसान बनाता है.

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

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

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

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

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

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

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