注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

グループの管理

サイドバーの Platform Settings セクションで Groups を選択します。グループを選択して、その詳細をダッシュボードビューで表示します。

Manage groups

選択したグループに関するさまざまな情報を表示できます。

  • グループ名: グループ名の変更は推奨されませんが、Manage 権限を持つユーザーは変更できます(以下の グループの名前変更 を参照)。
  • グループの説明: グループを説明し、グループを発見できるすべての組織のユーザーに表示されます。
  • グループ ID: グループの永続的で一意の ID。
  • グループタイプ: グループのタイプ。外部、内部、または ルールベース。内部のレルムグループのメンバーシップは Foundry で管理されます。
  • レルム: 認証ソース。外部または内部。外部グループの場合、レルムはグループを管理するプロバイダーを識別します。
  • 組織: このグループとその説明を表示できる組織のメンバーを定義します。
  • メンバー: このグループのメンバーであるユーザー。これには、個々のユーザーやグループが含まれます。
  • グループ権限: グループの管理権限を持つユーザーを定義します。管理権限には 2 種類あります。
    • Manage permissions: グループの管理権限、メンバーの管理、メタデータの編集権限を付与できるユーザー。
    • Manage membership: メンバーシップの有効期限プロパティを含むグループのメンバーを管理できるユーザー。
  • 属性: 他の Foundry サービスで一般的に使用されるキーと値の形式で保存されるグループに関する情報。

グループの組織で View group membership 権限を持っている場合のみ、グループを表示できます。この権限は Settings > Platform Settings > Organizations から、関心のある組織を選択して ManageOrganization permissions を選択することで付与できます。これにより、ユーザーとグループのリストおよび検索ボックスが表示されます。追加されたユーザーとグループに対して、ドロップダウンボックスを使用して View group membership オプションを有効にします。

メンバーシップの有効期限

特定のグループで Manage membership ができる場合、新しいメンバーシップが一時的であることを要求できます。以下のグループプロパティを設定してこれを行います。

  • 最新の有効期限: すべての新しいメンバーシップは、この日付より前に有効期限を持つ必要があります。
  • 最大期間: すべての新しいメンバーシップは、指定された期間内に有効期限を持つ必要があります。

これらのプロパティのいずれかまたは両方を同時に設定できます。両方が設定されている場合、最新の許可された有効期限は、2 つの中で最も制約のあるプロパティになります。

さらに、Manage membership 権限を持っている場合、メンバーシップの有効期限プロパティが設定された一時的なメンバーをグループに追加できます。最新の有効期限 または 最大期間 プロパティが設定されていないグループにこれらの一時的なメンバーを追加できます。

いずれかの 最新の有効期限 または 最大期間 プロパティを持つグループのメンバーシップリクエストを引き起こす アクセスリクエスト は、最大の有効期限によって制約されます。

メンバーシップの有効期限通知

一時的なグループメンバーシップが期限切れになると、影響を受けるユーザーに取り消し通知が送信されます。さらに、一時的なメンバーシップを持つユーザーは、有効期限の 7 日前にリマインダー通知を受け取ります。ただし、ユーザーが 7 日未満の有効期限を持つグループに追加された場合、リマインダー通知は受け取りません。

これらの通知を受け取りたくない場合は、プラットフォームサイドバーの Account > Settings > Notifications でプラットフォーム通知設定を構成できます。

カスタム承認のアクセスリクエストフォーム

プロジェクトで定義された役割を持つグループに対して Manage permissions を持っている場合、次の構造を使用してグループに属性を追加することで、そのプロジェクトのカスタム アクセスリクエスト フォームを構成できます。

  • 属性キー: access-request:'group-category-name'
  • 属性値: 'intended group value'

これらの属性は、グループの Attributes に追加すると、ユーザーがアクセスリクエストフォームの一部として選択できる Request access ポップアップウィンドウの一部として自動的に表示されます。

たとえば、次のグループ属性を追加すると、以下のカスタムリクエストフローが生成されます。

  • キー: access-request: Team
  • 値: blue

Example of custom access request flow resulting from group attribute setting

カスタムアクセスリクエストフォームは、複数のグループがあるプロジェクトに特に役立ちます。これにより、管理者とユーザーの体験を向上させるための合理化された直感的なアクセスリクエストプロセスが提供されます。

カスタム承認のアクセスリクエストポリシー

カスタムポリシーはベータ版の状態であり、ユーザーのエンロールメントでは利用できない場合があります。この機能を有効にしたい場合は、Palantir サポートにお問い合わせください。

グループに対して Manage membership または Manage Permissions 権限を持つユーザーは、選択したグループのメンバーシップリクエストを引き起こす アクセスリクエスト に適用されるカスタムポリシーを構成できます。それは以下に示すように Membership Approval セクションで構成できます。

Manage group Approvals policy

グループにカスタムポリシーが構成されている場合、そのグループへのリクエストが発生するアクセスリクエストに影響を与えます。カスタムポリシーは、特定のグループにメンバーを追加する Group membership サブタスクに適用されます。アクセスリクエストが承認されるためには、すべてのサブタスクが承認される必要があります。承認ポリシーは、アクセスをリクエストする際と既存のアクセスリクエストをレビューする際に両方で伝達されます。

Custom policy Approvals access request

プロジェクトアクセス

Details タブの横にある Project access を選択して、選択したグループのプロジェクトアクセスの詳細を表示します。

Group project access

Project access ビューでは、グループ管理者がグループがアクセスできるすべてのプロジェクトとグループに付与された特定のプロジェクトロールを確認できます。このビューは、ユーザーをグループに追加または削除する際にアクセスがどのように変化するかを確認するのに特に役立ちます。

Show inherited permissions トグルはデフォルトで on になっており、ネストされたすべてのグループをトラバースしてグループがアクセスできるプロジェクトを見つけます。このトグルを off にすると、グループが直接適用されたプロジェクトのみがリストに表示されます。

Project access tab

グループの名前変更

Manage membership 権限を持つユーザーはグループの名前を変更できます。ユーザーがグループの名前を変更すると、自動的にいくつかのアクションが実行されます。

  • 現在のグループが名前変更され、グループ ID はそのままです。
  • 元の名前を持つ新しいグループが作成され、元のグループ名に依存するアプリケーションをサポートします。
  • 元のグループは、新しく名前変更されたグループのメンバーになります。

連絡先の設定

グループの連絡先として連絡先の詳細を指定できます。manage permissions グループのユーザーは権限を管理できます。ユーザーは、グループが Foundry Issues を通じて連絡されるか、指定されたメールによって連絡されるかを定義できます。

Set contact details for a group

プロジェクトリソースサイドバーでグループをプロジェクトの連絡先として設定する場合、連絡先の詳細を設定すると便利です。プロジェクトの連絡先は、プロジェクトオーナーがプロジェクト概要の Project point of contact セクションで Add を選択することで設定できます。

Set contact details for a project

グループ権限の適用

Group details ダッシュボードから Group Permissions ビューにアクセスします。Manage permissions を持つユーザーは、このセクションを使用して、個々のユーザーではなくグループにアクセス権限を付与することで、権限をより透明で監査可能にすることができます。

グループ権限の付与は、プロジェクトに対する権限を割り当てる際に特に便利です。管理者は、上記の Project access タブを介してグループがアクセスできるプロジェクトを確認できるためです。すべてのデフォルトの役割に対して、少なくとも 3 つのグループ(Viewer、Editor、および Owner)を持つプロジェクト設定を推奨します。プロジェクトのデフォルトの役割を Discoverer に設定する必要があります。

Group project roles

制限付きビューのグループ名ポリシー

Group name をポリシー用語の 1 つとして使用する制限付きビューを作成する場合、グループ名を一致させるためにグループのレルムを指定する必要があります。Platform Settings > Groups インターフェースでグループのレルムを確認し、制限付きビューのルールエディターの下部でレルム名を変更できます。

Restricted view groups

レルム

ユーザーレルム

管理者は通常、Control Panel で外部のレルムプロバイダー(SSO、SAML レルム、または ADFS など)を設定します。必要に応じて、Foundry の Platform Settings には、アイデンティティプロバイダーの内部実装が付属しています。この内部アイデンティティプロバイダーは、外部認証システムが適さないさまざまなシナリオで使用できます。

グループ外部レルム

外部レルムは、ADFS などのアイデンティティプロバイダーから直接派生したグループです。Platform Settings の構成により、アイデンティティプロバイダーが割り当てられるレルムが定義されます。

外部レルムは Foundry で変更できず、読み取り専用の状態で存在します。外部システムでのみ実行できる操作には、名前の変更、ユーザーのグループへの追加、属性の変更、新しいグループの作成などがあります。外部レルムグループは、Foundry での認可および認証関連の機能に最適です。これには以下が含まれます。 * 任意および必須の制御の割り当て * プラットフォームへのバイナリアクセスの有効化(特定のグループに属するユーザーのセットを許可または拒否するなど)

外部レルムグループは読み取り専用の状態であるため、ユーザーは Foundry で外部レルムグループに参加するためのアクセスをリクエストすることはできません。ただし、Control Panel で、外部レルムグループへのアクセスをリクエストしようとするユーザーが受け取るメッセージを構成できます。Control Panel > Authentication > Your SSO > SAML > Manage > Attribute mapping > External group management に移動して、外部レルムのカスタムメッセージと URL を設定します。外部レルムと同じレルム内のユーザーのみがカスタムメッセージと URL を表示します。以下は、管理者が内部 Jira インスタンスへのメッセージとリンクを追加した例です。

Create a custom message in Control Panel

カスタムメッセージが構成されると、外部レルムのすべてのグループを表示する際に、Platform Settings でこのメッセージが表示されます。

View custom message in Platform Settings

ユーザーがこのグループに役割を付与するプロジェクトへのアクセスをリクエストしようとすると、メッセージが表示されます。

external group request access

最後に、ログイン時に組織の割り当てのために外部レルムグループを使用できます。顧客の SSO を介して取得された情報は、ログイン時にユーザーを異なる組織にトリアージするための入力となることがよくあります。

すべての外部レルムグループには組織が割り当てられている必要があります。組織が割り当てられていない場合、そのグループは組織に関係なくすべてのユーザーに表示されます。

グループ内部レルム

Foundry で作成されたグループは内部レルムに割り当てられます。

内部レルムグループは Foundry 内で変更できます。Groups インターフェースで実行できる操作には、名前の変更、ユーザーのグループへの追加、属性の変更、新しいグループの作成などがあります。内部レルムグループは、Foundry レベルの機能へのアクセスを付与するのに最適です。これには、サービスユーザーアカウントを内部レルムグループにバンドルして、許可リストまたは拒否リストの目的で使用することが含まれます(たとえば、ユーザーアカウントの有効期限ルールからサービスユーザーアカウントを除外するなど)。

外部レルムグループが使用されている場合、ユーザーを内部レルムグループに直接割り当てるのは避けることが重要です。代わりに、ユーザーが追加/削除される外部レルムグループを内部レルムグループ内にネストする必要があります。