همگام سازی سیستم های هویتی مختلف

کنترل دسترسی در جستجوی ابری گوگل بر اساس حساب کاربری گوگل کاربر است. هنگام نمایه‌سازی محتوا، همه ACLهای موجود در موارد باید به شناسه‌های معتبر کاربر Google یا گروه (آدرس ایمیل) برسند.

در بسیاری از موارد، یک مخزن اطلاعات مستقیمی از حساب‌های Google ندارد. در عوض، کاربران ممکن است با حساب‌های محلی نشان داده شوند یا از ورود به سیستم فدرال با ارائه‌دهنده هویت و شناسه، به غیر از آدرس ایمیل کاربر، برای شناسایی هر حساب استفاده کنند. این شناسه شناسه خارجی نامیده می شود.

منابع Identity که با استفاده از کنسول Admin ایجاد شده‌اند، به پر کردن این شکاف بین سیستم‌های هویت از طریق:

• تعریف یک فیلد کاربری سفارشی برای ذخیره شناسه های خارجی. این فیلد برای شناسایی شناسه‌های خارجی یک حساب Google استفاده می‌شود.
• یک فضای نام برای گروه های امنیتی که توسط یک مخزن یا ارائه دهنده هویت مدیریت می شوند، تعریف کنید.

از منابع هویتی استفاده کنید زمانی که:

• مخزن از آدرس ایمیل اصلی کاربر در Google Workspace یا Google Cloud Directory اطلاعی ندارد.
• مخزن گروه هایی را برای کنترل دسترسی تعریف می کند که با گروه های مبتنی بر ایمیل در Google Workspace مطابقت ندارند.

منابع هویتی با جدا کردن نمایه سازی از نقشه هویت، کارایی نمایه سازی را بهبود می بخشند. این جداسازی به شما این امکان را می دهد که جستجوی کاربر را هنگام ایجاد ACL و نمایه سازی موارد به تعویق بیندازید.

استقرار نمونه

شکل 1 یک نمونه استقرار را نشان می دهد که در آن مخازن داخلی و ابری توسط یک شرکت استفاده می شود. هر مخزن از نوع متفاوتی از شناسه خارجی برای ارجاع به کاربران استفاده می کند.

مخزن 1 کاربر را با استفاده از آدرس ایمیل اعلام شده با استفاده از SAML شناسایی می کند. از آنجایی که مخزن 1 از آدرس ایمیل اصلی کاربر در Google Workspace یا Cloud Directory اطلاع دارد، منبع هویتی لازم نیست.

مخزن 2 مستقیماً با دایرکتوری داخلی ادغام می شود و کاربر را با ویژگی sAMAccountName شناسایی می کند. از آنجا که مخزن 2 از ویژگی sAMAccountName به عنوان شناسه خارجی استفاده می کند، یک منبع هویت مورد نیاز است.

یک منبع هویت ایجاد کنید

اگر به منبع هویت نیاز دارید، به شناسه‌های کاربر Map در جستجوی ابری مراجعه کنید.

قبل از ایجاد یک رابط محتوا باید یک منبع هویت ایجاد کنید زیرا برای ایجاد ACL و داده های فهرست به شناسه منبع هویت نیاز دارید. همانطور که قبلا ذکر شد، ایجاد یک منبع هویت همچنین یک ویژگی کاربر سفارشی در Cloud Directory ایجاد می کند. از این ویژگی برای ثبت شناسه خارجی برای هر کاربر در مخزن خود استفاده کنید. ویژگی با استفاده از قرارداد IDENTITY_SOURCE_ID _identity نامگذاری شده است.

جدول زیر دو منبع هویت را نشان می دهد، یکی برای نگهداری نام حساب های SAM (sAMAccountName) به عنوان شناسه های خارجی و دیگری برای نگهداری شناسه های کاربر (uid) به عنوان شناسه های خارجی.

برای هر شناسه خارجی احتمالی که برای ارجاع به کاربر در شرکت شما استفاده می شود، یک منبع هویت ایجاد کنید.

جدول زیر نشان می دهد که چگونه کاربری با یک حساب Google و دو شناسه خارجی (id1_identity و id2_identity) و مقادیر آنها در Cloud Directory ظاهر می شود:

می‌توانید با استفاده از سه شناسه مختلف (ایمیل Google، sAMAccountName و uid) هنگام تشکیل ACL برای نمایه‌سازی، به یک کاربر ارجاع دهید.

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 برای شناسه هنگام ایجاد اصول استفاده می کند. با مراجعه به جداول قبلی، اگر یک ACL با id1_identity Ann (SAMAccountName) ایجاد کنید، شناسه به صورت زیر حل می شود:

identitysources/id1_identity/users/example/ann

کل این شناسه، شناسه میانی کاربر نامیده می‌شود، زیرا پل ارتباطی بین شناسه خارجی و شناسه‌های Google ذخیره شده در Cloud Directory ایجاد می‌کند.

برای اطلاعات بیشتر در مورد مدل سازی ACL های مورد استفاده برای یک مخزن، 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 را با استفاده از کلاس Acl.Builder به صورت زیر بسازید:

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

اتصال دهنده های هویت

در حالی که می‌توانید از شناسه‌های خارجی و غیر Google برای ایجاد ACL و فهرست‌بندی موارد استفاده کنید، کاربران نمی‌توانند موارد را در جستجو ببینند تا زمانی که شناسه‌های خارجی آن‌ها به شناسه Google در فهرست Cloud تبدیل شود. سه راه برای اطمینان از اینکه Cloud Directory هم شناسه Google و هم شناسه های خارجی کاربر را می داند وجود دارد:

• به‌روزرسانی دستی هر نمایه کاربر از طریق کنسول مدیریت این فرآیند فقط برای آزمایش و نمونه‌سازی با استفاده از چند پروفایل کاربر توصیه می‌شود.
• شناسه‌های خارجی را با استفاده از Directory API به شناسه‌های Google نگاشت کنید. این فرآیند برای کسانی که نمی توانند از Identity Connector SDK استفاده کنند توصیه می شود.
• با استفاده از Identity Connector SDK یک رابط هویت ایجاد کنید . این SDK استفاده از Directory API را برای نقشه‌برداری شناسه‌ها ساده می‌کند.

رابط‌های هویت برنامه‌هایی هستند که برای نگاشت شناسه‌های خارجی از هویت سازمانی (کاربران و گروه‌ها) به هویت‌های داخلی Google مورد استفاده توسط Google Cloud Search استفاده می‌شوند. اگر باید یک منبع هویت ایجاد کنید، باید یک اتصال دهنده هویت ایجاد کنید.

Google Cloud Directory Sync (GCDS) نمونه ای از اتصال دهنده هویت است. این رابط هویت، اطلاعات کاربر و گروه را از Active Directory مایکروسافت به Cloud Directory همراه با ویژگی‌های کاربری که ممکن است هویت آنها را در سیستم‌های دیگر نشان دهد، نگاشت می‌کند.

هویت ها را با استفاده از REST API همگام سازی کنید

از روش update برای همگام سازی هویت ها با استفاده از REST API استفاده کنید.

نقشه برداری مجدد هویت ها

پس از نگاشت مجدد هویت یک مورد به هویت دیگر، باید موارد را مجدداً فهرست کنید تا هویت جدید ثابت شود. به عنوان مثال،

• اگر می‌خواهید نقشه‌ای را از یک کاربر حذف کنید یا آن را به کاربر دیگری بازنگری کنید، نگاشت اصلی همچنان حفظ می‌شود تا زمانی که دوباره فهرست کنید.
• اگر یک گروه نگاشت شده را که در یک آیتم ACL وجود دارد حذف کنید، و سپس یک گروه جدید با همان groupKey ایجاد کنید، گروه جدید تا زمانی که مورد مجدداً فهرست نشود، دسترسی به مورد را فراهم نمی کند.