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

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

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

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

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

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

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

مثال استقرار

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

مثال استقرار
شکل 1. نمونه‌ای از استقرار سازمانی با انواع مختلف هویت

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

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

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

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

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

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

منبع هویت ملک کاربر شناسه خارجی
شناسه1 شناسه_شناسایی ... نام حساب sAMA
شناسه۲ شناسه_id2 شناسه کاربری

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

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

کاربر ایمیل شناسه_شناسایی ... شناسه_id2
آن ann@example.com مثال\ann ۱۰۰۱

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

نوشتن ACL های کاربر

برای ایجاد مدیران اصلی با استفاده از یک شناسه خارجی ارائه شده، از متد getUserPrincpal() یا متد getGroupPrincipal() استفاده کنید.

مثال زیر نحوه بازیابی مجوزهای فایل را نشان می‌دهد. این مجوزها شامل نام هر کاربری است که به فایل دسترسی دارد.

نمونه مجوز فایل.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();
  // ...
}

قطعه کد زیر نحوه ایجاد مدیران اصلی (Principal) که مالک هستند را با استفاده از شناسه خارجی ( externalUserName ) ذخیره شده در ویژگی‌ها (attributes) نشان می‌دهد.

نمونه مجوز فایل.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)
);

در نهایت، قطعه کد زیر نحوه ایجاد مدیران اصلی که خواننده فایل هستند را نشان می‌دهد.

نمونه مجوز فایل.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 را ایجاد کنید:

نمونه مجوز فایل.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();

API اصلی REST هنگام ایجاد مدیران اصلی از الگوی identitysources/ IDENTITY_SOURCE_ID /users/ EXTERNAL_ID برای شناسه استفاده می‌کند. با مراجعه به جداول قبلی، اگر یک ACL با id1_identity (SAMAccountName) مربوط به Ann ایجاد کنید، شناسه به صورت زیر تبدیل می‌شود:

identitysources/id1_identity/users/example/ann

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

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

گروه‌های نقشه

منابع هویت همچنین به عنوان یک فضای نام برای گروه‌هایی که در ACLها استفاده می‌شوند، عمل می‌کنند. شما می‌توانید از این ویژگی فضای نام برای ایجاد و نگاشت گروه‌هایی که فقط برای اهداف امنیتی استفاده می‌شوند یا در یک مخزن محلی هستند، استفاده کنید.

از API گروه‌های هویت ابری برای ایجاد یک گروه و مدیریت عضویت‌ها استفاده کنید. برای مرتبط کردن گروه با یک منبع هویت، از نام منبع منبع هویت به عنوان فضای نام گروه استفاده کنید.

قطعه کد زیر نحوه ایجاد یک گروه با استفاده از API گروه‌های هویت ابری (Cloud Identity Groups API) را نشان می‌دهد:

دستور CreateGroup.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 گروهی

برای ایجاد یک ACL گروهی، از متد getGroupPrincipal() برای ایجاد یک مدیر گروه با استفاده از یک شناسه خارجی ارائه شده استفاده کنید. سپس، ACL را با استفاده از کلاس Acl.Builder به شرح زیر بسازید:

نمونه مجوز فایل.java
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

رابط‌های هویت

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

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

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

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

همگام‌سازی هویت‌ها با استفاده از REST API

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

تغییر نقشه هویت‌ها

پس از تغییر هویت یک آیتم به هویت دیگر، باید آیتم‌ها را برای تثبیت هویت جدید، دوباره فهرست‌بندی کنید. برای مثال،

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