SCIM でユーザーをプロビジョニング

プロビジョニングの動作

• 入社。 プロバイダーでユーザーをアプリケーションに割り当てると、screenRIG がそのアカウントを作成し、組織のメンバーにします。ユーザーはシングルサインオンでサインインし、パスワードを持ちません。グループがプロジェクトを付与するまで、プロジェクトは持ちません。
• 異動。 プロジェクトに紐付けられたグループは、そのメンバーにそのプロジェクトを付与します。グループへの参加または脱退で、アクセスが追加または削除されます。
• 退職。 ユーザーを無効化するか割り当てを解除すると、そのセッションとアクセスが終了します。ユーザーが承認したエージェントと OAuth グラントは、ユーザープロビジョニングまたは screenRIG スタッフによってそのユーザーが無効化されるまで動作し続けます。シングルサインオンの必須化や、プロバイダーでのユーザーの無効化では終了しません。

始める前に

• シングルサインオンが設定済みで、組織に検証済みドメインがあります。プロビジョニングで作成されるのは、検証済みドメインのアドレスのみです。
• あなたは組織の管理者です。

オンにする

1. 組織設定でユーザープロビジョニング (SCIM)を開き、プロビジョニングをオンにするを選択します。ベース URL（https://api.screenrig.ai/scim/v2）をコピーします。これはダッシュボードのオリジンではなく、API のオリジンにあります。
2. プロビジョニングトークンで、トークンを作成を選択し、トークン名（たとえば Entra）を入力して確定します。今すぐトークンをコピーしてください。srscim_ に 43 文字が続く形式で、一度だけ表示されます。screenRIG はハッシュのみを保持します。

プロビジョニングのオンとトークンの作成には、パスキーまたはパスワードが求められます。代わりに、プロバイダーがユーザーをいつ認証したかを示している場合に限り、シングルサインオンのセッションが 10 分間、直近のサインインとして扱われます。示していない場合は、ダッシュボードがユーザーにプロバイダーで再度サインインするよう求めます。

組織が保持できるトークンは最大 5 つです。ローテーションするには、新しいトークンを作成してプロバイダーに貼り付け、その後に古いトークンを取り消します。その間もプロビジョニングは動作し続けます。一覧には各トークンの最終利用日時が表示されます。プロビジョニングをオフにすると、すべてのリクエストが 403 を返し、誰のアクセスも変わりません。

Microsoft Entra ID

1. エンタープライズアプリケーション（シングルサインオンを担うもの）を開き、Provisioning を選択して、Provisioning Mode を Automatic に設定します。
2. Admin Credentials で、ベース URL を Tenant URL、トークンを Secret Token として入力します。Test Connection を選択し、続けて Save を選択します。
3. Mappings、Provision Microsoft Entra ID Users を開きます。userName を userPrincipalName からマッピングし（ユーザープリンシパル名がユーザーのサインインに使うアドレスと異なる場合は mail から）、emails[type eq "work"].value を mail からマッピングし、active はデフォルトの Switch([IsSoftDeleted], , "False", "True", "True", "False") のままにします。Entra が提案するその他のマッピングはそのまま維持します。screenRIG は勤務先のメールアドレスを使用し、なければプライマリメールアドレス、それもなければ userName を使用します。このアドレスは検証済みドメインのもので、かつシングルサインオンが送信するアドレスと一致している必要があります。
4. グループ単位でアクセスを付与するには、Provision Microsoft Entra ID Groups を有効のままにします。
5. Settings で Scope を Sync only assigned users and groups に設定し、Users and groups でユーザーとグループを割り当てます。
6. Provisioning Status を On に設定して保存します。Entra は最初のサイクルを実行し、その後は約 40 分ごとに同期します。Provision on demand を使うと、1 人のユーザーまたは 1 つのグループを直ちに同期できます。

Okta

1. screenRIG アプリケーションを開きます。General で App Settings を編集し、Provisioning を SCIM に設定します。
2. Provisioning、Integration、Edit を開きます。ベース URL を SCIM connector base URL に入力し、userName を Unique identifier field for users に入力します。Push New Users、Push Profile Updates、Push Groups にチェックを入れ、Authentication Mode を HTTP Header に設定します。カスタム SCIM アプリでは、トークンを HTTP Header フィールドに貼り付けます。Okta が API Token を求める場合（Okta の SCIM テストアプリ）は、Bearer、スペース 1 つ、トークンの順に入力します。どちらでも動作します。Test Connector Configuration を選択し、続けて Save を選択します。
3. To App、Edit の順に開き、Create Users、Update User Attributes、Deactivate Users を有効にします。Sync Password はオフのままにします。screenRIG はパスワードを無視します。
4. Sign On で Application username format を Email に設定します。
5. Assignments でユーザーとグループを割り当て、Push Groups で紐付けるグループをプッシュします。

Okta は active: false でユーザーを無効化し、削除することはありません。

グループとプロジェクト

プロビジョニングされたグループは、組織設定のユーザープロビジョニング (SCIM) にあるプロビジョニング済みのグループに、メンバー数と紐付けられたプロジェクトとともに一覧表示されます。プロジェクトで承認できるユーザーが紐付けるまで、グループはアクセスを付与しません：

1. プロジェクトでアクセスを開き、続けてグループを開きます。どのメンバーも紐付けを閲覧でき、プロジェクトのオーナー、承認できるメンバー、メンバーである組織の管理者がグループを紐付けます。
2. グループを紐付けで、グループとロールを選択します。メンバーは通常のメンバーシップ、承認者はレビューの承認も行います。グループを紐付けを選択します。紐付けを外すで紐付けを解除します。

紐付けは、付与する内容をスクリーンフォルダーとスクリーンに限定することもできます。これは、メンバーを限定できるのと同じスクリーンスコープです。グループを紐付けでプロジェクト全体または画面を限定を選択します（承認者の紐付けではフォルダーのみを指定できます）。プロジェクト内でのユーザーのスクリーンは、その紐付けのスコープの和集合で、スコープのない紐付けが1つでもあればプロジェクト全体になります。ユーザーが承認できるのは、承認者の紐付けがそれらのスクリーンすべてを網羅する範囲だけで、1つのフォルダーの承認者とプロジェクト全体のメンバーを併せ持つと、プロジェクト全体の通常のメンバーになります。プロビジョニングは、手動で付与されたアクセスを下げることはなく、ユーザーが作成したサービスクライアントが有効な間は、そのユーザーを限定しません。そのような拒否はいずれも、ユーザープロビジョニングの最近のアクティビティに表示され、クライアントを取り消すと、次の同期でスコープが適用されます。紐付けのスコープは固定で、変更するには紐付けを削除して、もう一度グループを紐付けます。

• スコープがない場合、複数の紐付けられたグループに属するユーザーは、最も高いロールを持ちます。承認者はメンバーより上位です。
• グループへの参加または脱退で、メンバーシップが追加または削除されます。グループの紐付けを解除するか、プロバイダーでグループを削除すると、そのグループが付与していた内容は撤回されます。
• プロビジョニングが削除するのは、自らが追加したものだけです。手動で付与したメンバーシップは残り、グループによって承認者に引き上げられたメンバーは、グループを抜けると元のロールに戻ります。
• 組織のメンバーは、すべてのプロジェクトを合わせて最大 200 人で、同じ人は 1 人として数えます。受け入れられなかったユーザーはプロビジョニングイベントに失敗として記録され、それ以外は何も変わりません。
• グループが付与するのはプロジェクトのロールのみで、組織の管理者権限は付与しません。管理者が見られるのは紐付けとプロジェクト名で、プロジェクトの内容は見られません。

プロビジョニングできるユーザー

• 検証済みドメインのアドレスにアカウントがない場合は、パスワードなしでアカウントが作成されます。
• パスワードもパスキーも持たないユーザー、お客様の組織が管理しているユーザー、またはシングルサインオンを必須にしている組織のユーザーは、引き継がれ、シングルサインオンでサインインします。
• すでに独自のサインインを持ち、お客様の組織のプロジェクトのいずれかのメンバーであるユーザーは、組織がシングルサインオンを必須にしていない限り、アクセスのみを目的にリンクされます。プロビジョニングが管理するのはお客様のプロジェクトへのアクセスのみで、名前、メールアドレス、サインインは管理しません。
• それ以外のユーザーは、理由を示すエラーで拒否されます。拒否されるのは、お客様のプロジェクトのメンバーではない独自のサインインを持つアカウント、別の組織が管理しているユーザー、そして screenRIG スタッフです。このようなユーザーはまずお客様のプロジェクトのいずれかに招待してください。その後、プロビジョニングがアクセスのためにリンクします。

無効化と DELETE

active: false は、PUT または PATCH で送信した場合も DELETE と同様に、ユーザーのアクセスを終了します。active: true は、表にあるとおり無効化を元に戻します。

お客様のプロビジョニング以外（screenRIG スタッフなど）によって無効化されたユーザーは、無効化されたままです。active: true は 400 mutability で失敗します。ユーザーが所有するプロジェクトが移管されることはありません。リンクされたユーザーはそのプロジェクトへのアクセスを維持し、管理対象ユーザーのプロジェクトは、再有効化までアカウントのほかの部分とともに保留されます。ほかのユーザーが管理を続ける必要がある場合は、オーナーを無効化する前に所有権を移してください。組織の最後の管理者は、管理対象ユーザーとして無効化できません。リクエストは 400 mutability で失敗するため、先に別の管理者を追加してください。

参照

ベース URL は https://api.screenrig.ai/scim/v2 です。トークンは Authorization: Bearer srscim_TOKEN に指定し、トークンのみの指定も受け付けられます。リクエストとレスポンスは application/scim+json で、application/json も受け付けられます。

フィルターは、and で結合した 1～4 個の attribute eq value 項です。値は引用符付きの文字列、または active に対する true か false です。ユーザーは userName（大文字小文字を区別しません）、externalId（完全一致）、id、emails または emails.value、displayName、active で絞り込めます。グループは displayName、externalId、id、および members または members.value で絞り込めます。それ以外は 400 invalidFilter です。

PATCH は、Entra と Okta が送信する形式のまま操作を読み取ります。?aadOptscim062020 の有無は問いません。操作名は大文字小文字を区別せず、ブール値は true、false、"True" または "False" です。操作では path を省略することも、{"name.givenName": "Ada"} のようなドット区切りのキーを使うこともできます。パスには emails[type eq "work"].value、members（値の配列を伴う追加、置換、削除）、members[value eq "<id>"]（削除）があります。screenRIG が使用しない属性は受け付けられ、無視されます。

制限。 組織は、アドレスごとではなく、すべてのトークンを合わせて 1 分あたり 600 リクエストまで送信できます。Entra と Okta は送信元アドレスを共有するためです。上限を超えると Retry-After 付きの 429 を返します。認証の失敗は、アドレスごとに 10 分あたり 30 回に制限されます。

エラーは scimType を含む SCIM エンベロープで返されます（invalidFilter、uniqueness、mutability など）：

{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "status": "409", "scimType": "uniqueness", "detail": "…" }

組織設定のユーザープロビジョニングには、30 日間保持される最新の 500 件のリクエストが、失敗とその理由も含めて一覧表示されます。何かが届かない場合は、まずそこを確認してください。

トラブルシューティング

関連

• シングルサインオン：Entra ID、Okta、Google Workspace またはその他のプロバイダーを接続し、必須にします。
• 認証：エージェントのサインイン方法とアクセスの承認方法。
• API リファレンス：/scim/v2 とプロビジョニングのルート。