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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इंडेक्स करने के लिए एसीएल बनाते समय, तीन अलग-अलग आईडी (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);
}

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

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

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

डेटा स्टोर करने की जगह के लिए इस्तेमाल किए जाने वाले ACL को मॉडल करने के बारे में ज़्यादा जानकारी के लिए, 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);
}

समूह ACL बनाएं

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

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

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

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

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

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

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

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

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

पहचान फिर से मैप की जा रही हैं

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

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