SCIM ユーザー同期

注:

パブリック プレビュー: SCIM ユーザー同期はパブリック プレビューの段階です。

この機能は、Enterprise ライセンス プランで利用できます。

注:

利用可能な機能は、使用するクラウド製品によって異なります。詳しくは、「 機能の提供状況」をご覧ください。

SCIM (クロスドメイン ID 管理システム) ディレクトリ連携を使用すると、企業はユーザー ID とライフサイクル イベントを UiPath とその企業 ID プロバイダー (IdP) との間で安全に同期できます。

SCIM ユーザー同期は、既存の Microsoft Entra ID と Security Assertion Markup Language (SAML) ベースのシングル サインオン (SSO) 連携に基づいて構築されており、ユーザーの作成、更新、プロビジョニング解除を自動化し、一元管理を維持したまま、手動による ID 管理をなくします。

主な機能

ユーザーのライフサイクル管理の自動化

ユーザーの作成、更新、削除を IdP と UiPath 間で同期します。

ユーザー属性の同期

ユーザー属性 (名前、電子メール、役職、部署、およびその他の属性) は、SCIM ソース ディレクトリの指示に従って自動的に更新されます。変更は、再ログインを必要とせずに UiPath に反映されます。

プロビジョニング解除とコンプライアンス

安全なアクセス制御を確保し、従業員が組織を離れるときにライセンスの割り当てを解除することで、データの保持と監査の要件に準拠するのに役立ちます。

サポートされている ID プロバイダー

• Microsoft Entra ID (Azure AD)
• Okta

サポートされている SCIM 操作

リソース	操作	説明
ユーザー	取得、投稿、保存、パッチ適用、削除	ユーザーを取得、作成、変更、または非アクティブ化する
グループ	サポート対象外	グループとグループ メンバーシップは SCIM を介して同期されません

SCIM User Sync は ユーザーのみを プロビジョニングし、グループとグループ メンバーシップは同期されません。各 SSO 方式でのグループベースのアクセスの動作については、 次の「SSO 方式別の機能比較 」セクションを参照してください。

SCIM 2.0 サーバーは、SCIM ベース URL (セットアップの SCIM URL など) の下に標準のサービス検出エンドポイントも公開 https://cloud.uipath.com/{orgId}/identity_/api/scim/v2。

• .../ServiceProviderConfig
• .../ResourceTypes
• .../Schemas

これらのエンドポイントは、SCIM 認証トークンで認証された要求を受け入れ、サポートされているサーバー機能、リソースの種類、およびスキーマを返します。

ユーザー ライフサイクル管理

SCIM は、次のライフサイクル イベントを管理します。

• プロビジョニング: ユーザーがソース ディレクトリに割り当てられると、IdP によってそのユーザーが UiPath にプッシュされます。
• 更新: ソース ディレクトリでユーザーの属性が変更されると、IdP は更新を UiPath にプッシュします。
• プロビジョニング解除:
  • 非アクティブ化: ソース ディレクトリでユーザーが非アクティブ化または割り当て解除されると、UiPath はそのユーザーを非アクティブ化済みとしてマークします。
  • 削除: ソース ディレクトリからユーザーを削除すると、UiPath はそのユーザーを削除します。
• 再アクティブ化: ソース ディレクトリでユーザーが再アクティブ化されると、UiPath はそのユーザーを再アクティブ化します。再アクティベーション後に、ライセンスを再割り当てする必要があります。

以下の表では、各ライフサイクル イベントが UiPath に与える影響について説明します。

	作成	更新する	ディアクティベーションする	削除する
管理者 — ユーザーとグループの管理	ユーザーは、グループ、ロール、および権限を照会して割り当てることができます。	ユーザー属性が更新されました。	すべてのロールと権限は保持されます。	ユーザーのすべてのレコードが削除されます。
ライセンス管理	—	—	ユーザーのライセンスが解放され、利用可能なプールに戻ります。	ユーザーのライセンスが解放され、利用可能なプールに戻ります。
ファーストパーティ サービス (Orchestrator、Automation Hub、Task Mining)	—	—	ユーザーは非アクティブとマークされます。それらを参照する成果物には、非アクティブなインジケーターが表示されます。	ユーザーが削除されます。それらを参照する成果物には、非アクティブなインジケーターが表示されます。
その他	今後のリリース	今後のリリース	今後のリリース	今後のリリース

注:

ユーザーが削除されたときだけでなく、ID プロバイダーで非アクティブ化または無効化されると、UiPath はそのライセンスを自動的に解放し、再割り当てのために利用可能なプールに戻します。これにより、離脱したユーザーや非アクティブなユーザーから、手動でクリーンアップすることなくライセンスを再利用できます。ユーザーが後で再アクティブ化された場合は、ライセンスを再割り当てする必要があります。

認可方法

ID プロバイダーに応じて、次の認可方法を使用できます。

認可方法	Entra ID	Okta
有効期間が長いベアラー トークン	サポート対象	サポート対象
OAuth 認可コードの付与	サポート対象外	サポート対象
OAuth クライアント資格情報の付与	サポート対象	サポート対象外

SCIM を有効にした場合のディレクトリ動作

SCIM が有効化されている場合、UiPath はディレクトリ ユーザーを SCIM 経由でプロビジョニングされたユーザーから排他的に調達します。UiPath 管理ポータルやディレクトリ API を使用したユーザー検索など、ディレクトリ ユーザーの検索やクエリが行われる場所では、SCIM でプロビジョニングされたユーザーのみが返されます。これは、Microsoft Entra ID と SAML の両方の連携に適用されます。

• Microsoft Entra ID: UiPath はユーザーを取得するために Microsoft Graph API を呼び出すのではなく、SCIM でプロビジョニングされたディレクトリからユーザーが提供されます。(グループ検索では、引き続きリアルタイムの Graph API 呼び出しが使用されます)。
• SAML: SCIM を使用してプロビジョニングされなかったユーザーは、ディレクトリの結果から除外されます。

重要:

サインインできるユーザーのセットは、SCIM を介してプロビジョニングされたユーザーのセットとまったく同じである必要があります。ディレクトリ クエリでは SCIM でプロビジョニングされたユーザーのみが返されるため、認証はできるが SCIM を使用してプロビジョニングされていないユーザーは、UiPath で見つけたり、権限を割り当てられたり、その他の方法で管理したりすることはできません。SSO アプリケーションと SCIM アプリケーションに割り当てられたユーザーは同一である必要があります。

SSO方式による機能比較

次の表では、組織に構成されている SSO 方式に応じて SCIM User Sync がどのように動作するかを比較しています。

	Entra ID、SSO + SCIM	SAML SSO + SCIM
ディレクトリ ユーザーはどのようにログインしていますか?	OpenID Connect (OIDC) プロトコルを使用した、組織固有の URL を介したシングル サインオン。	SAML 2.0 プロトコルを使用した、組織固有の URL を介したシングル サインオン。
ディレクトリ ユーザーはいつ、どのようにプロビジョニングされますか?	ユーザーは、設定時に SCIM のソース ディレクトリから UiPath にプロビジョニングされます。後続の更新は非同期的にプッシュされます。	ユーザーは、設定時に SCIM のソース ディレクトリから UiPath にプロビジョニングされます。後続の更新は非同期的にプッシュされます。
ディレクトリ ユーザー属性はいつ、どのように更新されますか?	ユーザー属性は、SCIM ソース ディレクトリの指示に従って、UiPath で非同期的に更新されます。	ユーザー属性は、SCIM ソース ディレクトリの指示に従って、UiPath で非同期的に更新されます。
ディレクトリ ユーザーはいつ、どのようにプロビジョニング解除または非アクティブ化されますか?	ユーザーは、SCIM ソース ディレクトリの指示に従って、UiPath で非同期的にプロビジョニング解除または非アクティブ化されます。	ユーザーは、SCIM ソース ディレクトリの指示に従って、UiPath で非同期的にプロビジョニング解除または非アクティブ化されます。
ディレクトリ グループはいつ、どのようにプロビジョニングされますか?	ディレクトリ グループは SCIM 経由でプロビジョニングされませんが、UiPath で権限またはロールを割り当てると、キャッシュされたディレクトリに具体化されます。	ディレクトリ グループは SCIM 経由でプロビジョニングされません。
ディレクトリ グループ メンバーシップの評価方法	グループ メンバーシップは、リアルタイムの Microsoft Graph API 呼び出しで評価されます。	グループ メンバーシップは SCIM では評価されません。Just-In-Time (JIT) プロビジョニング ルールでは、SAML クレームに基づいてユーザーをローカルの UiPath グループに配置できます。
ディレクトリ ユーザーはどのように検索され、権限が割り当てられますか?	SCIM でプロビジョニングされたユーザーの UiPath のキャッシュ ディレクトリに対して呼び出しが実行されます。ディレクトリ ユーザーにクエリを実行するには、Enterprise SSO を使用してサインインする必要があります。	SCIM でプロビジョニングされたユーザーの UiPath のキャッシュ ディレクトリに対して呼び出しが実行されます。ディレクトリ ユーザーにクエリを実行するには、Enterprise SSO を使用してサインインする必要があります。
ディレクトリ グループはどのように検索され、アクセス許可が割り当てられますか?	リアルタイムの Microsoft Graph API 呼び出しを介して、ローカル ユーザーの場合は UiPath のディレクトリ、ディレクトリ グループの場合は Entra ID を呼び出します。	ディレクトリ グループに対してクエリを実行することはできません。JIT プロビジョニング ルールは、ユーザーをローカルの UiPath グループに自動的に配置するように設定できます。

属性マッピング

次の表は、SCIM 属性と UiPath のユーザー属性のマップを示しています。ID プロバイダーは SCIM 属性を送信します。UiPath はこれを UiPath のユーザー属性として保存します。

SCIM 属性	UiPath のユーザー属性	Required
externalId	ユーザーの照合とリンクに使用されるディレクトリ識別子	はい
userName	ユーザー名	はい
displayName	表示名	はい
emails[type eq "work"].value	メール
name.givenName	名
name.familyName	姓
title	役職
addresses[type eq "work"].locality	市町村
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department	Department
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization	会社名

注:

externalId 、プロビジョニングされた各ユーザーを UiPath が識別してリンクする方法であるため、ユーザーのディレクトリ ID として保存される、安定した一意のユーザーである必要があります。Okta によって externalId が自動的に入力されます。Microsoft Entra ID では、SCIM 属性マッピングで明示的に (通常はユーザーのオブジェクト ID に) マップする必要があります。

SCIM プロビジョニングを有効にする前に、ID プロバイダーの属性マッピングにこれらの必須フィールドが含まれている必要があります。

重要:

ID プロバイダーが送信する属性は、前述の属性マッピングの表に記載されているように、UiPath が期待する SCIM 属性にマップする必要があります。SAML SSO を使用する場合、SAML 属性マッピングでこれらの値が生成される必要があります。特に、SCIM を介して送信される userName は、SAML アサーションで使用される識別子と一致する必要があります。これにより、プロビジョニングされたユーザーとユーザーの SSO ログインが同じ UiPath ユーザーに解決されます。

制限事項

• 古いユーザー: 既存の非アクティブなユーザーは自動的には削除されません。今後の更新では、非アクティブなユーザーをクリーンアップするためのツールが提供される予定です。
• グループおよびグループ メンバーシップの同期: サポートされていません。
• 一貫したユーザー セット: SSO 用に構成されたユーザーのセットは、SCIM 同期用に構成されたユーザーのセットと一致する必要があります。

レート制限

SCIM 要求は、組織ごとにレート制限されています。

要求の種類	上限量
読み取り要求 ( 読み取りGET)	5 分あたり 300 件の要求
書き込み要求 (POST、 PUT、 PATCH、 DELETE)	5 分あたり 160 件の要求

これらの制限を超える要求は、HTTP 429 Too Many Requests 応答を受け取ります。ID プロバイダー コネクタはバックオフし、調整された要求を自動的にリトライします。そのため、プロビジョニングは手動による介入なしで続行されます。

セットアップ ガイド

SCIM User Sync を有効化するには、ID プロバイダーに対して SSO を構成する必要があります。セットアップ ガイドは、以下の製品で利用できます。

• Microsoft Entra ID を使用した SCIM ユーザー同期の設定
• Okta との SCIM ユーザー同期の構成