- 基本情報
- データのセキュリティとコンプライアンス
- 組織
- 認証とセキュリティ
- ライセンス
- テナントとサービス
- アカウントとロール
- 外部アプリケーション
- 組織でのテスト
- AI Trust Layer
- 通知
- ログ
- トラブルシューティング
Automation Cloud (公共部門向け) 管理ガイド
Automation Cloud で SAML を構成することにより、認証のセキュリティと効率の両方が強化されます。UiPath のシステムでは、SAML を使用してセキュリティで保護されたアクセス トークンによるシングル サインオン (SSO) を実現しています。これにより、UiPath Platform は SAML 2.0 標準を使用する任意の ID プロバイダー (IdP) に接続できます。
さらに、SAML構成にはシングルログアウト(SLO)機能が含まれており、IdPで統合されたすべてのアプリケーション間での同時ログアウトが可能です。
SAML 連携は、既存のユーザーの混乱を招くことなく、段階的に導入することができます。
ネイティブの Microsoft Entra ID 連携から SAML 連携に切り替える
認証に Microsoft Entra ID を使用している場合は、より豊富な機能を持つネイティブの Microsoft Entra ID 連携の使用をお勧めします。
SAML 連携に切り替える場合は、アクセス スキーマを完全に再作成する必要がないように、ディレクトリ グループを介して行われるロールの割り当てを、ディレクトリ アカウントへの直接ロールの割り当てに手動で置き換える必要があります。
-
ID プロバイダーからの暗号化された SAML アサーションはサポートされていません。
-
ID プロバイダーからユーザーおよびグループを検索することはできません。 検索できるのは、プロビジョニングされたディレクトリ ユーザーのみです。
-
組織レベルでディレクトリ ユーザーを表示することはできません。組織レベルで表示されるのはローカル ユーザーのみです。ディレクトリ ユーザーは Just-In-Time プロビジョニングで追加されるため、Automation Cloud の [アカウントとグループ] ページには表示されません。
-
SAML 連携を使用してサインインするディレクトリ ユーザーは、ユーザー キーを使用して API 要求を認可できる API アクセス情報を表示できません。
SAML 連携を設定するには、以下が必要です。
-
Automation Cloud 組織とサードパーティ ID プロバイダーの両方における管理者権限。ID プロバイダーの管理者権限がない場合は、管理者とともに設定プロセスを完了できます。
-
UiPath® Studio および UiPath Assistant のバージョン 2020.10.3 以降 (推奨されるデプロイを使用するよう設定できるようにするため)。
組織でメール アドレスを再利用している場合は、SAML 連携を設定する前に、非アクティブなユーザー アカウントをすべて削除することが重要です。
連携を有効化すると、Automation Cloud に存在するローカル アカウントを、同じメール アドレスを使用する外部 ID プロバイダーのディレクトリ アカウントにリンクできます。このアカウントのリンクは、メール アドレスを持つディレクトリ アカウント ユーザーが初めてサインインするときに行われます。ID プロバイダーの ID はローカル アカウントからすべてのロールを継承するため、移行はシームレスに行われます。このため、Automation Cloud に非アクティブなローカル アカウントが存在すると、ローカル アカウントとディレクトリ アカウントが一致しなくなり、権限が意図せず昇格されてしまうリスクがあります。
非アクティブなユーザー アカウントを削除するには、以下の手順を実行します。
次に、連携のために Automation Cloud と ID プロバイダー (IdP) の両方を設定する必要があります。
手順 2.1: SAML サービス プロバイダーの詳細情報を取得する
- ページの上部には、ID プロバイダーの構成に必要な UiPath の情報 ( メタデータ URL、 アサーション コンシューマー サービス URL、 エンティティ ID) が表示されます。 ID プロバイダーを設定するために、それらをコピーして保存します。重要: ID プロバイダーの構成プロセスの一環として、UiPath のメタデータ URL を使用することを強くお勧めします。こうすると、UiPath が署名証明書のローテーションを開始した場合に常に自動更新できるため、プラットフォームを中断なく動作させることができます。
このブラウザー タブは、後で使用するために開いたままにします。
手順 2.2: ID プロバイダーを設定する
SAML 2.0 標準を使用する任意のサードパーティの ID プロバイダー (IdP) に接続できます。設定は選択した IdP によって異なることがありますが、Okta または PingOne を使用する場合の設定は検証済みです。連携を設定する際の参考にしてください。
他の ID プロバイダーについては、それぞれの連携に関するドキュメントに従ってください。
手順 2.3.Automation Cloud を構成する
ID プロバイダーを認識するサービス プロバイダーとして Automation Cloud を有効化するには、次の手順に従います。
- [ID プロバイダーを設定] ページの 2 番目のセクションでは、Automation Cloud で ID プロバイダーを設定するために必要なフィールドを参照できます。[メタデータ URL] フィールドに、ID プロバイダーのメタデータ URL を入力します。これにより、Automation Cloud が ID プロバイダーから定期的にデータを取得して更新できるようになり、SAML 構成プロセスを長期的に効率化できます。重要: SAML の構成時には、メタデータ URL を使用することを強くお勧めします。これにより、UiPath は ID プロバイダーからデータを定期的に取得して更新できるため、ID プロバイダーの署名証明書をローテーションする際に UiPath で手動で更新する必要がなくなります。
- 複数の証明書を手動で入力するには、証明書の開始と終了のインジケーターで囲み、改行文字で区切って Base64 エンコードで [ 署名証明書 ] フィールドに貼り付けます。 たとえば、証明書が 2 つある場合は、次の形式を使用する必要があります。
-----BEGIN CERTIFICATE----- <base64 encoded certificate retrieved from SAML metadata URL or SAML admin> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <base64 encoded certificate retrieved from SAML metadata URL or SAML admin> -----END CERTIFICATE----------BEGIN CERTIFICATE----- <base64 encoded certificate retrieved from SAML metadata URL or SAML admin> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <base64 encoded certificate retrieved from SAML metadata URL or SAML admin> -----END CERTIFICATE-----
手順 2.4: 連携が実行中であることを確認する
SAML SSO 連携が正しく機能していることを確認するには、以下の手順を実行します。
- シークレット ブラウザー ウィンドウを開きます。
- Automation Cloud の組織の URL に移動します。
- 以下を確認します。
- SAML ID プロバイダーでサインインを求められるか。
- 正常にサインインできるか。
- 既存のユーザー アカウントと一致するメール アドレスでサインインしている場合、適切な権限を持っているか。
手順 2.5.プロビジョニング ルールを設定する (任意)
IdP でクレームを使用すると、クレームをプロビジョニング ルールの条件として活用し、ユーザーが Automation Cloud にサインインするときに、適切なライセンスとロールを持つ状態で自動的にプロビジョニングされるようにできます。プロビジョニング ルールは、ユーザーがサインインしたときに評価されます。ユーザー アカウントがルールの条件を満たしている場合、そのユーザー アカウントはルールに関連付けられたローカルの UiPath グループに自動的に追加されます。たとえば管理者は、これらの設定を使用して、Automation Users グループにユーザーを直接プロビジョニングするルールを設定できます。例: クレーム=group、リレーションシップ=is、値=Automation User
2.5.1 プロビジョニング グループを設定します。
Automation Cloud でアカウントをグループに追加すると、そのアカウントは、グループに対して定義されたライセンス、ロール、ロボットの設定がある場合はそれらを継承します。
類似するアカウントの種類 (開発者、テスターなど) をグループ化すると、Automation Cloud へのユーザーのオンボーディング プロセスを効率化できます。必ず、IdP にも類似するアカウントを同じ方法で設定してください。
つまりグループを一度設定すれば、必要に応じてそのグループにアカウントを追加することで設定を複製できます。特定のアカウント グループの設定を変更する必要がある場合は、グループを 1 回更新するだけでグループ内のすべてのアカウントに変更が適用されます。
プロビジョニング ルール用にグループを設定する方法
-
Automation Cloud に新しいローカル グループを作成します。
新しいグループを作成する代わりに、既存のグループのいずれかを使用することもできます。
-
(任意かつユーザー ライセンス管理が有効化されている必要があります。)グループのアカウントがユーザー ライセンスを必要とする場合は、グループにライセンスの割り当てルールを設定します。
既存のグループを使用している場合は、グループのライセンス割り当てを確認し、適切なライセンスが割り当てられていることを確認します。割り当てが適切でない場合は、割り当てを変更するか、新しいグループを作成します。
-
テナント ロールを割り当て、必要に応じてグループのロボットの設定を完了します。手順については、「ロールをグループに割り当てる」をご覧ください。
既存のグループを使用している場合は、グループに現在割り当てられているロールを確認して、グループに追加するアカウントの種類に適切なロールが割り当てられていることを確認します。適切なロールが割り当てられていない場合は、グループに割り当てられたロールを編集するか、新しいグループを作成します。
-
必要に応じて、グループをフォルダーに追加し、フォルダー ロールを割り当てます。手順については、「フォルダーへのアクセス権を管理する」をご覧ください。
これで、このグループをプロビジョニング ルールで使用できます。
2.5.2. グループのプロビジョニング ルールを作成します
SAML プロビジョニング ルールに関連付けられた要求を SAML アプリケーションで設定し、SAML ペイロードに送信されるようにします。
SAML 連携の設定後かつグループの設定後に以下の手順を実行します。
-
[管理] に移動し、組織を選択して [セキュリティ] を選択します。
組織の [セキュリティ設定] ページが開き、[認証設定] タブが表示されます。
-
[SAML SSO] オプション下の [プロビジョニング ルールを表示] を選択します。[SAML SSO プロビジョニング ルール] ページが開き、既存のルールが表示されます。
-
ページの右上隅にある [ルールを追加] を選択します。
[新しいルールを追加] ページが開きます。
- [基本情報] の下の [ルール名] フィールドに入力します。必要に応じて [説明] フィールドにも入力します。
-
[条件] の下の [ルールを追加] を選択します。
新しい条件のフィールド行が追加されます。これらのフィールドの組み合わせで、アカウントがグループに追加されるためにサインイン時に満たす必要がある条件を定義します (グループは後で選択)。
- [ 要求 ] フィールドに、IdP に表示される要求の名前を入力します。 このフィールドでは大文字と小文字が区別されます。
-
[リレーションシップ] リストから、クレームと値がどのような条件の組み合わせになるか選択します。下表のオプションを使用できます。
Relationship
条件の要件
例
次の値に等しい
完全一致、大文字と小文字が区別される
Department is RPA(部署 次に等しい RPA) の場合、Department(部署) クレームの値がRPAである必要があります。たとえば、値がRPADevである場合は条件は満たされません。このリレーションシップは複数の値を持つクレームに対して機能します。
たとえば、administrator値とdeveloper値がGroupクレームの下で送信される場合、Group is administratorは有効なリレーションシップです。次の値に等しくない
指定された値以外、大文字と小文字が区別される
Department is not ctr(部署 次の値に等しくない ctr) では、Department(部署) に値ctrが含まれていない、すべてのアカウントがグループに追加されます。部署がCtrまたはelectrである場合は条件が満たされます。次の値を含む
値を含む、完全一致を必要としない、大文字と小文字が区別される
Department contains RPA(部署 次の値を含む RPA) は、Department(部署( クレームの値がRPAを含む必要があります。たとえば、値がRPADev、xRPAx、またはNewRPAの場合は条件が満たされます。次の値を含まない
値を含まない、完全一致を必要としない、大文字と小文字が区別される
Department not contains ctr(部署 次の値を含まない ctr) の場合、Department(部署) の値にctrが含まれていない場合は、すべてのアカウントがグループに追加されます。たとえば、部署がctrまたはelectrであるアカウントは、グループに追加されません。次の値に等しい (大文字と小文字を区別しない)
完全一致、大文字と小文字が区別されない
Department is case insensitive RPA(部署 次の値に等しい (大文字と小文字を区別しない) RPA) は、Department(部署) クレームの値がrpaである必要があります。大文字と小文字は区別されません。たとえば、値がrpaの場合は条件が満たされます。値がcrpaである場合は条件は満たされません。次の値を含む (大文字と小文字を区別しない)
値を含む、完全一致を必要としない、大文字と小文字が区別されない
Department contains case insensitive RPA(部署 次の値を含む (大文字と小文字を区別しない) RPA) は、Department(部署) クレームの値がRPAを含む必要があります。大文字と小文字は区別されません。たとえば、値がrpa、cRPA、またはrpAの場合は条件が満たされます。 - [値] フィールドに、条件を満たすために必要な値を入力します。
-
別の条件を追加する場合は、[ルールを追加] を選択して新しい条件の行を追加します。
複数の条件を追加した場合、プロビジョニング ルールが適用されるには、すべての条件が満たされる必要があります。たとえば、Department is RPA(部署、次の値に等しい、RPA) とTitle is Engineer(役職、次の値に等しい、エンジニア) というルールを定義すると、RPA 部に所属し、かつ役職がエンジニアであるユーザーのみが指定したグループに追加されます。部署が RPA で、タイトルが QA であるアカウントは、グループに追加されません。 -
[グループに割り当て] の下の [グループを追加] ボックスにグループ名を入力し、結果のリストからグループを選択します。必要に応じて、手順を繰り返してさらにグループを追加します。
条件が満たされると、ログイン時にこれらのグループにアカウントが自動的に追加されます。
- 右下の [保存] を選択してルールを追加します。
ルールが設定されている状態で、ユーザーがログインした際にそのアカウントがルールで指定した条件を満たしていると、そのアカウントがルールにアタッチされたプロビジョニング グループに追加され、Automation Cloud で使用できるようセットアップされます。
サンプル SAML ペイロードフラグメント
<Attribute
Name="groups">
<AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ProcessAutomation-Developer</AttributeValue><Attribute
Name="groups">
<AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ProcessAutomation-Developer</AttributeValue>SAML 属性マッピング
-
IdP は、ACS ペイロードでこれらの要求を渡すように構成する必要があります。
-
IdP で設定された属性名が、組織管理者ポータルの属性マッピング設定と一致していることを確認します。
{
"displayname": "John Doe",
"fname": "John",
"lname": "Doe",
"jobtitle": "Hardware Engineer",
"dpt": "Engineering",
"city": "Phoenix"
}{
"displayname": "John Doe",
"fname": "John",
"lname": "Doe",
"jobtitle": "Hardware Engineer",
"dpt": "Engineering",
"city": "Phoenix"
}この組織のユーザーが SAML ディレクトリ連携を介してログインすると、ユーザー オブジェクトが更新され、この設定が反映されます。
{
"Display Name": "John Doe",
"First Name": "John",
"Last Name": "Doe",
"Job Title": "Hardware Engineer",
"Department": "Engineering",
"City": "Phoenix"
}{
"Display Name": "John Doe",
"First Name": "John",
"Last Name": "Doe",
"Job Title": "Hardware Engineer",
"Department": "Engineering",
"City": "Phoenix"
}必ず Automation Cloud の組織用の組織固有の URL をすべてのユーザーに提供してください。
SAML 連携に切り替えると、Microsoft Entra ID 連携は無効化されます。Microsoft Entra ID グループの割り当ては適用されなくなるため、Microsoft Entra ID から継承された Automation Cloud グループ メンバーシップと権限は考慮されなくなります。
SAML SSO を使用して Automation Cloud にサインインするには、以下の手順を実行します。
- 組織固有の URL に移動します。URL は組織 ID を含み、スラッシュで終る必要があります (例:
https://govcloud.uipath.us/orgID)。 - https://govcloud.uipath.us に移動します。ログイン ページで [ SSO で続行 ] を選択し、組織固有の URL を指定します。
SAML SSO を使用して UiPath Studio と UiPath Assistant にサインインするには、Assistant を以下のように設定する必要があります。
この手順は、連携を有効化したときに、これまで Automation Cloud を使用したことがないため Automation Cloud でローカル アカウントが設定されていない新しいユーザーにのみ必要となります。
新しいユーザーは、外部 IdP で使用されたメール アドレスによって Automation Cloud グループに追加できます。ユーザーがグループに割り当てられるか、ユーザーがサインインすると、UiPath のすべてのサービスでユーザーを検索してロールを割り当てられるようになります。
すべてのユーザーが SAML SSO に移行し、新しいユーザーが設定されたら、管理者アカウント以外のすべてのローカル ユーザー アカウントを削除することをお勧めします。これにより、そのユーザーはローカル アカウントの資格情報でサインインできなくなり、SAML SSO でサインインしなければならなくなります。
ローカル ユーザー アカウントは、そのアイコンに基づいて識別できます。
ローカル アカウントは次のような場合に便利です。
-
SAML 連携の問題を管理する場合 (期限切れの証明書の更新など)、または認証設定を変更する場合 - Organization Administrator のロールを持つアカウントの使用をお勧めします。
