বিভিন্ন পরিচয় সিস্টেম সিঙ্ক

Google ক্লাউড অনুসন্ধানে অ্যাক্সেস নিয়ন্ত্রণ ব্যবহারকারীর Google অ্যাকাউন্টের উপর ভিত্তি করে। বিষয়বস্তু ইন্ডেক্স করার সময়, আইটেমের সমস্ত ACL-কে অবশ্যই বৈধ Google ব্যবহারকারী বা গ্রুপ আইডি (ইমেল ঠিকানা) সমাধান করতে হবে।

অনেক ক্ষেত্রে একটি সংগ্রহস্থলের Google অ্যাকাউন্ট সম্পর্কে সরাসরি জ্ঞান থাকে না। পরিবর্তে, ব্যবহারকারীদের স্থানীয় অ্যাকাউন্ট দ্বারা প্রতিনিধিত্ব করা যেতে পারে বা প্রতিটি অ্যাকাউন্ট শনাক্ত করতে ব্যবহারকারীর ইমেল ঠিকানা ব্যতীত একটি পরিচয় প্রদানকারী এবং আইডি দিয়ে ফেডারেটেড সাইন-ইন ব্যবহার করতে পারে। এই আইডিটিকে বলা হয় এক্সটার্নাল আইডি ।

অ্যাডমিন কনসোল ব্যবহার করে তৈরি করা হয়েছে, আইডেন্টিটি সোর্স আইডেন্টিটি সিস্টেমের মধ্যে এই ব্যবধান পূরণ করতে সাহায্য করে:

• বহিরাগত আইডি সংরক্ষণ করার জন্য একটি কাস্টম ব্যবহারকারী ক্ষেত্র সংজ্ঞায়িত করা। ক্ষেত্রটি একটি Google অ্যাকাউন্টে বহিরাগত আইডি সমাধান করতে ব্যবহৃত হয়।
• একটি সংগ্রহস্থল বা পরিচয় প্রদানকারী দ্বারা পরিচালিত নিরাপত্তা গোষ্ঠীগুলির জন্য একটি নামস্থান সংজ্ঞায়িত করুন৷

পরিচয় সূত্র ব্যবহার করুন যখন হয়:

• Google Workspace বা Google ক্লাউড ডিরেক্টরিতে ব্যবহারকারীর প্রাথমিক ইমেল ঠিকানা সম্পর্কে তথ্য সংগ্রহস্থলে নেই।
• রিপোজিটরি অ্যাক্সেস কন্ট্রোলের জন্য গোষ্ঠীগুলিকে সংজ্ঞায়িত করে যেগুলি Google Workspace-এর ইমেল-ভিত্তিক গোষ্ঠীগুলির সাথে সম্পর্কিত নয়।

আইডেন্টিটি সোর্স আইডেন্টিটি ম্যাপিং থেকে ইনডেক্সিং ডিকপলিং করে ইন্ডেক্সিং দক্ষতা উন্নত করে। এই ডিকপলিং আপনাকে ACL এবং ইন্ডেক্সিং আইটেমগুলি তৈরি করার সময় ব্যবহারকারীর সন্ধান পিছিয়ে দেওয়ার অনুমতি দেয়।

উদাহরণ স্থাপন

চিত্র 1 একটি উদাহরণ স্থাপনা দেখায় যেখানে একটি এন্টারপ্রাইজ দ্বারা অন-প্রিমিস এবং ক্লাউড রিপোজিটরি উভয়ই ব্যবহৃত হয়। প্রতিটি সংগ্রহস্থল ব্যবহারকারীদের উল্লেখ করার জন্য একটি ভিন্ন ধরনের বাহ্যিক ID ব্যবহার করে।

রিপোজিটরি 1 SAML ব্যবহার করে দাবি করা ইমেল ঠিকানা ব্যবহার করে ব্যবহারকারীকে শনাক্ত করে। যেহেতু রিপোজিটরি 1-এর কাছে Google Workspace বা ক্লাউড ডিরেক্টরিতে ব্যবহারকারীর প্রাথমিক ইমেল ঠিকানা সম্পর্কে জ্ঞান রয়েছে, তাই কোনও পরিচয়ের উৎসের প্রয়োজন নেই।

রিপোজিটরি 2 সরাসরি একটি অন-প্রিমিস ডিরেক্টরির সাথে সংহত করে এবং ব্যবহারকারীকে তাদের sAMAccountName বৈশিষ্ট্য দ্বারা চিহ্নিত করে। যেহেতু রিপোজিটরি 2 একটি sAMAccountName অ্যাট্রিবিউট একটি বহিরাগত আইডি হিসাবে ব্যবহার করে, একটি পরিচয় উত্স প্রয়োজন৷

একটি পরিচয় উৎস তৈরি করুন

আপনার যদি একটি পরিচয় উৎসের প্রয়োজন হয়, তাহলে ক্লাউড অনুসন্ধানে ম্যাপ ব্যবহারকারীর পরিচয় দেখুন।

একটি বিষয়বস্তু সংযোগকারী তৈরি করার আগে আপনাকে অবশ্যই একটি পরিচয় উৎস তৈরি করতে হবে কারণ ACL এবং সূচক ডেটা তৈরি করতে আপনার পরিচয় উৎস আইডির প্রয়োজন হবে। পূর্বে উল্লিখিত হিসাবে, একটি পরিচয় উৎস তৈরি করা ক্লাউড ডিরেক্টরিতে একটি কাস্টম ব্যবহারকারী সম্পত্তি তৈরি করে। আপনার সংগ্রহস্থলে প্রতিটি ব্যবহারকারীর জন্য বাহ্যিক আইডি রেকর্ড করতে এই সম্পত্তি ব্যবহার করুন। প্রপার্টির নামকরণ করা হয়েছে কনভেনশন IDENTITY_SOURCE_ID _identity ব্যবহার করে।

নিম্নলিখিত সারণী দুটি পরিচয়ের উত্স দেখায়, একটি বহিরাগত আইডি হিসাবে SAM অ্যাকাউন্টের নাম (sAMAccountName) রাখা এবং একটি বহিরাগত ID হিসাবে ব্যবহারকারী আইডি (uid) রাখা।

প্রতিটি সম্ভাব্য বাহ্যিক আইডির জন্য একটি পরিচয় উৎস তৈরি করুন যা আপনার এন্টারপ্রাইজের একজন ব্যবহারকারীকে উল্লেখ করতে ব্যবহৃত হয়।

নিম্নলিখিত সারণীটি দেখায় যে কীভাবে একটি Google অ্যাকাউন্ট এবং দুটি বাহ্যিক আইডি (id1_identity এবং id2_identity) সহ ব্যবহারকারী এবং তাদের মানগুলি ক্লাউড ডিরেক্টরিতে প্রদর্শিত হয়:

সূচীকরণের জন্য 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);
}

একবার আপনার পাঠক এবং মালিকদের একটি তালিকা হয়ে গেলে, আপনি 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 ব্যবহার করে। পূর্ববর্তী সারণীগুলিতে ফিরে উল্লেখ করে, আপনি যদি Ann's id1_identity (SAMAccountName) দিয়ে একটি ACL তৈরি করেন, তাহলে ID সমাধান করবে:

identitysources/id1_identity/users/example/ann

এই সম্পূর্ণ আইডিটিকে ব্যবহারকারীর মধ্যবর্তী আইডি বলা হয় কারণ এটি ক্লাউড ডিরেক্টরিতে সংরক্ষিত বাহ্যিক আইডি এবং Google আইডিগুলির মধ্যে একটি সেতু প্রদান করে৷

একটি সংগ্রহস্থলের জন্য ব্যবহৃত ACL-এর মডেলিং সম্পর্কে আরও তথ্যের জন্য, ACLs দেখুন।

মানচিত্র গ্রুপ

পরিচয় সূত্রগুলি 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 ক্লাস ব্যবহার করে ACL তৈরি করুন:

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

পরিচয় সংযোগকারী

আপনি যখন ACL এবং সূচীপত্র তৈরি করতে বাহ্যিক, নন-Google আইডি ব্যবহার করতে পারেন, তখন ব্যবহারকারীরা তাদের বাহ্যিক আইডি ক্লাউড ডিরেক্টরিতে Google আইডিতে সমাধান না হওয়া পর্যন্ত অনুসন্ধানে আইটেমগুলি দেখতে পাবেন না। ক্লাউড ডিরেক্টরি ব্যবহারকারীর জন্য Google আইডি এবং বাহ্যিক আইডি উভয়ই জানে কিনা তা নিশ্চিত করার তিনটি উপায় রয়েছে:

• অ্যাডমিন কনসোলের মাধ্যমে প্রতিটি স্বতন্ত্র ব্যবহারকারীর প্রোফাইল ম্যানুয়ালি আপডেট করুন এই প্রক্রিয়াটি শুধুমাত্র কয়েকটি ব্যবহারকারীর প্রোফাইল ব্যবহার করে পরীক্ষা এবং প্রোটোটাইপ করার জন্য সুপারিশ করা হয়।
• ডিরেক্টরি এপিআই ব্যবহার করে Google আইডিতে বাহ্যিক আইডি ম্যাপ করুন। যারা আইডেন্টিটি কানেক্টর SDK ব্যবহার করতে পারেন না তাদের জন্য এই প্রক্রিয়াটি সুপারিশ করা হয়।
• আইডেন্টিটি কানেক্টর SDK ব্যবহার করে একটি আইডেন্টিটি কানেক্টর তৈরি করুন । এই SDK আইডি ম্যাপ করতে ডিরেক্টরি API- এর ব্যবহারকে সহজ করে।

আইডেন্টিটি কানেক্টর হল এমন প্রোগ্রাম যা এন্টারপ্রাইজ আইডেন্টিটি (ব্যবহারকারী এবং গোষ্ঠী) থেকে Google ক্লাউড সার্চ দ্বারা ব্যবহৃত অভ্যন্তরীণ Google পরিচয়ে বাহ্যিক আইডি ম্যাপ করতে ব্যবহৃত হয়। যদি আপনাকে একটি পরিচয় উৎস তৈরি করতে হয়, তাহলে আপনাকে অবশ্যই একটি পরিচয় সংযোগকারী তৈরি করতে হবে।

Google ক্লাউড ডিরেক্টরি সিঙ্ক (GCDS) হল একটি পরিচয় সংযোগকারীর উদাহরণ। এই আইডেন্টিটি কানেক্টরটি মাইক্রোসফটের অ্যাক্টিভ ডিরেক্টরি থেকে ক্লাউড ডিরেক্টরিতে ব্যবহারকারী এবং গোষ্ঠীর তথ্য ম্যাপ করে এবং ব্যবহারকারীর বৈশিষ্ট্যগুলি সহ অন্যান্য সিস্টেমে তাদের পরিচয় উপস্থাপন করতে পারে।

REST API ব্যবহার করে পরিচয় সিঙ্ক করুন

REST API ব্যবহার করে পরিচয় সিঙ্ক করতে update পদ্ধতি ব্যবহার করুন।

রিম্যাপিং পরিচয়

একটি আইটেমের পরিচয় অন্য পরিচয়ে রিম্যাপ করার পরে, নতুন পরিচয় ধরে রাখার জন্য আপনাকে অবশ্যই আইটেমগুলিকে পুনঃসূচীকরণ করতে হবে৷ যেমন,

• আপনি যদি একজন ব্যবহারকারীর কাছ থেকে ম্যাপিং অপসারণ করার চেষ্টা করেন বা অন্য ব্যবহারকারীর সাথে এটিকে রিম্যাপ করার চেষ্টা করেন, তবে মূল ম্যাপিংটি এখনও সংরক্ষিত থাকবে যতক্ষণ না আপনি পুনঃসূচীকরণ করেন।
• আপনি যদি একটি আইটেম ACL-তে উপস্থিত একটি ম্যাপ করা গোষ্ঠী মুছে ফেলেন এবং তারপরে একই groupKey দিয়ে একটি নতুন গ্রুপ তৈরি করেন, আইটেমটি পুনঃসূচীকরণ না হওয়া পর্যন্ত নতুন গ্রুপটি আইটেমটিতে অ্যাক্সেস প্রদান করে না।