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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उपयोगकर्ता email id1_identity id2_identity
आरती ann@example.com उदाहरण\ann 1001

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

उपयोगकर्ता के ACL लिखें

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

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

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 (SAMAccountName) के साथ ACL बनाया है, तो आईडी का समाधान हो जाएगा:

identitysources/id1_identity/users/example/ann

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

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

ग्रुप मैप करें

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

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

यह कोड स्निपेट, 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);
}

समूह ACL बनाएं

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

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

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

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

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

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

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

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

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

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

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

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