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

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

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

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

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

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

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

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

مثال استقرار

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

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

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

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

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

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

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

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

منبع هویت	ویژگی کاربر	شناسه خارجی
id1	id1_identity	sAMAccountName
id2	id2_identity	uid

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

این جدول نشان می‌دهد که چگونه یک کاربر با یک حساب گوگل و دو شناسه خارجی در فهرست ابری ظاهر می‌شود:

کاربر	ایمیل	id1_identity	id2_identity
آن	[e-mail]	example\ann	1001

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

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

برای ایجاد مدیران اصلی با استفاده از شناسه‌های خارجی، از getUserPrincipal() یا 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();
  // ...
}

این قطعه کد با استفاده از ویژگی externalUserName مدیران اصلی (Principals) را برای مالکان (owners) ایجاد می‌کند:

نمونه مجوز فایل.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 استفاده می‌کند. id1_identity کاربر به identitysources/id1_identity/users/example/ann تبدیل می‌شود. این شناسه میانی کاربر است.

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

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

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

از 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 گروهی

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

نمونه مجوز فایل.java

مشاهده در گیت‌هاب

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

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

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

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

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

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

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

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

تغییر نام هویت‌ها

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

• اگر نگاشت کاربر را حذف یا تغییر دهید، نگاشت اصلی تا زمان فهرست‌بندی مجدد باقی می‌ماند.
• اگر یک گروه نگاشت‌شده را حذف کنید و یک گروه جدید با همان groupKey ایجاد کنید، تا زمانی که دوباره فهرست‌بندی نکنید، دسترسی اعطا نمی‌شود.

،

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

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

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

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

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

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

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

مثال استقرار

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

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

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

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

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

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

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

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

منبع هویت	ویژگی کاربر	شناسه خارجی
id1	id1_identity	sAMAccountName
id2	id2_identity	uid

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

این جدول نشان می‌دهد که چگونه یک کاربر با یک حساب گوگل و دو شناسه خارجی در فهرست ابری ظاهر می‌شود:

کاربر	ایمیل	id1_identity	id2_identity
آن	[e-mail]	example\ann	1001

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

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

برای ایجاد مدیران اصلی با استفاده از شناسه‌های خارجی، از getUserPrincipal() یا 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();
  // ...
}

این قطعه کد با استفاده از ویژگی externalUserName مدیران اصلی (Principals) را برای مالکان (owners) ایجاد می‌کند:

نمونه مجوز فایل.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 استفاده می‌کند. id1_identity کاربر به identitysources/id1_identity/users/example/ann تبدیل می‌شود. این شناسه میانی کاربر است.

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

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

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

از 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 گروهی

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

نمونه مجوز فایل.java

مشاهده در گیت‌هاب

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

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

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

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

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

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

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

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

تغییر نام هویت‌ها

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

• اگر نگاشت کاربر را حذف یا تغییر دهید، نگاشت اصلی تا زمان فهرست‌بندی مجدد باقی می‌ماند.
• اگر یک گروه نگاشت‌شده را حذف کنید و یک گروه جدید با همان groupKey ایجاد کنید، تا زمانی که دوباره فهرست‌بندی نکنید، دسترسی اعطا نمی‌شود.