SAML 連携を設定する

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

UiPath で 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 プロビジョニングで追加されるため、UiPath の [アカウントとグループ ] ページには表示されません。

前提条件

SAML 連携を設定するには、以下が必要です。

• Enterprise タイプのライセンス プランです。ライセンス プランについて詳しくは、「 ユニファイド プライシング: ライセンス プランのフレームワーク」をご覧ください。
• UiPath 組織とサードパーティ ID プロバイダーの、両方の管理者権限。 ID プロバイダーの管理者権限がない場合は、管理者とともに設定プロセスを完了できます。
• UiPath® Studio および UiPath Assistant のバージョン 2020.10.3 以降 ( 推奨されるデプロイを使用するよう設定できるようにするため)。

手順 1: 非アクティブなユーザー アカウントをクリーンアップする

組織でメール アドレスを再利用している場合は、SAML 連携を設定する前に、非アクティブなユーザー アカウントをすべて削除することが重要です。

連携を有効化すると、UiPath に存在するローカル アカウントを、同じメール アドレスを使用する外部 ID プロバイダーのディレクトリ アカウントにリンクできます。このアカウントのリンクは、メール アドレスを持つディレクトリ アカウント ユーザーが初めてサインインするときに行われます。移行がシームレスに行われるように、ID プロバイダーの ID は、ローカル アカウントからすべてのロールを継承します。このため、UiPath に非アクティブなローカル アカウントが存在すると、ローカル アカウントとディレクトリ アカウントが一致しなくなり、権限が意図せず昇格されてしまうリスクがあります。

非アクティブなユーザー アカウントを削除するには、以下の手順を実行します。

1. UiPath に組織管理者としてログインします。

2. [管理] に移動し、組織を選択して [アカウントとグループ] を選択します。 組織の [アカウントとグループ ] ページが [ユーザー] タブに表示されます。

3. [ 最終操作日 ] 列の列ヘッダーを選択して、最終ログインの日付が最も古いユーザーが一番上に表示されるように、ユーザーを並べ替えます。[ 最終操作日 ] 列には、ユーザーが最後にログインした日付が表示されます。この列に [保留中] と表示されている場合、ユーザーがログインしたことがないことを示します。

4. 行の最後にある [ 削除 ] アイコンを選択して、そのユーザーのローカル アカウントを削除します。

   

5. 確認ダイアログの [ 削除 ] を選択して、UiPath からアカウントを削除します。ページからユーザー アカウントが削除されます。

6. 操作を続行して、組織の非アクティブなユーザー アカウントをすべて削除します。

手順 2: SAML 連携を設定する

続いて、連携のために UiPath と ID プロバイダー (IdP) の両方を設定する必要があります。

手順 2.1: SAML サービス プロバイダーの詳細情報を取得する

1. UiPath に組織管理者としてログインします。

2. [管理] に移動し、組織を選択して [セキュリティ] を選択します。 組織の [セキュリティ設定] ページが開き、[認証設定] タブが表示されます。

3. [SSO のディレクトリ連携] で、[SSO を構成] を選択します。[SSO の構成]ウィンドウが開き、連携の利点と前提条件の説明が表示されます。

4. 2 つの SSO オプションから [SAML 2.0] を選択します。[SAML SSO の構成] ページが開き、[ID プロバイダーを設定] タブが表示されます。

5. ページの上部には、ID プロバイダーの構成に必要な UiPath の情報 ( メタデータ URL、 アサーション コンシューマー サービス URL、 エンティティ ID) が表示されます。これらをコピーして保存し、ID プロバイダーを設定します。

   重要:

   ID プロバイダーの構成プロセスの一環として、UiPath の メタデータ URL を使用することを強くお勧めします。こうすると、UiPath が署名証明書のローテーションを開始した場合に常に自動更新できるため、プラットフォームを中断なく動作させることができます。

   

6. エンティティ ID には、既定で組織 ID が含まれます。この形式を変更してグローバル識別子 (組織 ID なし) を使用するには、[ エンティティ ID の形式を変更 ] オプションを使用します。次に、[ エンティティ ID の形式を変更 ] ウィンドウの [ エンティティ ID の形式 ] ドロップダウンで、[ 組織固有の識別子 ] を選択して組織 ID を含む形式を使用するか、[ グローバル識別子 ] を選択して組織 ID を含まない形式を使用します。組織固有の識別子を使用することをお勧めします。必要に応じて、複数の UiPath 組織を ID プロバイダーに登録できるためです。

このブラウザー タブは、後で使用するために開いたままにします。

手順 2.2: ID プロバイダーを設定する

SAML 2.0 標準を使用する任意のサードパーティの ID プロバイダー (IdP) に接続できます。設定は選択した IdP によって異なることがありますが、Okta または PingOne を使用する場合の設定は検証済みです。連携を設定する際の参考にしてください。

Okta を ID プロバイダーとして設定する

PingOne を ID プロバイダーとして設定する

他の ID プロバイダーについては、それぞれの連携に関するドキュメントに従ってください。

手順 2.3.UiPath クラウド プラットフォームを構成する

ID プロバイダーを認識するサービス プロバイダーとして UiPath Cloud Platform を有効化するには、次の手順に従います。

1. 組織の [SAML SSO の構成 ] タブに戻ります

2. [ID プロバイダーを設定] ページの 2 番目のセクションでは、ID プロバイダーの設定に必要なフィールドを参照できます。[ メタデータ URL ] フィールドに、ID プロバイダーのメタデータ URL を入力します。これにより、UiPath は ID プロバイダーからデータを定期的に取得して更新できるため、SAML の構成プロセスを長期にわたって効率化できます。

   重要:

   SAML の構成時には 、メタデータ URL を使用することを強くお勧めします。これにより、UiPath は ID プロバイダーからデータを定期的に取得して更新できるため、ID プロバイダーの署名証明書をローテーションする際に UiPath で手動で更新する必要がなくなります。

   

3. [ データを取得] を選択します。完了すると、[ サインオン URL]、[ ID プロバイダーのエンティティ ID]、および [署名証明書] フィールドに IdP の情報が入力されます。

4. これは推奨される方法ではありませんが、[ サインオン URL]、[ ID プロバイダーのエンティティ ID]、および [ 署名証明書 ] の各フィールドに、ID プロバイダーの SAML の詳細を手動で入力できます。

5. 複数の証明書を手動で入力するには、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-----
   

   

6. 右下隅にある [ 次へ ] を選択して次の手順に進みます。[ 属性をマッピングして完了 ] タブが表示されます。「クレーム」と呼ばれる属性をマッピングすることにより、ID プロバイダーと UiPath との間でユーザーの詳細をリンクします。これにより、メールやユーザー名などのユーザー データが両方のシステムで確実に一致します。

7. 既定では、メール アドレスがユーザーの識別子として使用されます。メール アドレスではない一意の識別子を設定するオプションが必要な場合は、UiPath サポートにお問い合わせください。それ以外の場合は、次の手順に従います。

   1. [メール アドレス] フィールドが必須になり、変更できなくなります。
   2. [許可されたドメイン] セクションに、ユーザーのサインインを許可するドメインを入力します。設定した ID プロバイダーでサポートされているすべてのドメインを入力します。複数のドメインを指定する場合は、コンマで区切ります。
      注:

      最大で 100 個のドメインを入力できます。

   3. [ 属性マッピング] の下の [ 表示名 ] フィールドに、ユーザーの名前として組織に表示する IdP の属性を入力します。「名」属性と「姓」属性を使用できます。
   4. 必要に応じて、ID プロバイダーからのそれぞれのクレームと組織内の対応する属性を指定して、新しいマッピングを追加します。

8. UiPath サポートに連絡してユーザーの一意の識別子を設定する場合は、[ カスタムの一意の識別子を有効化] オプションが表示されます。以下の手順は、Test Cloud および Test Cloud (公共部門向け) を使用している場合にのみ適用されます。Test Cloud (専有型) の場合、カスタム ID の有効化はサポート チームが処理します。

   警告:

   メール アドレスではない一意の識別子を有効にする前に、次の既知の影響を確認してください。

   • Orchestrator では、ロールを割り当てるために一意のメール アドレスが必要です。異なる一意の識別子を持つユーザー間でメール アドレスが同じ場合には、Orchestrator でロールを割り当てることができません。または、ユーザーが一意の識別子を持っており、メール アドレスがない場合は、Orchestrator で権限を割り当てることができます。
   • ユーザーが一意の識別子を持っている場合、メール アドレスに基づいてアカウントをリンクすることはできません。
   • メール アドレス フィールドが空白のままにされていると、ユーザーが UiPath Platform からメールを受け取ることはありません。
   • 設定した後に一意の識別子のクレーム名を変更すると、システムがユーザーを識別できなくなる可能性があり、以前は認識されていたユーザーが失われる場合があります。そのため、UI では、一意の識別子のクレームが設定された後の変更は制限されています。変更するには、構成全体を削除して再作成する必要があります。
   1. [ カスタムの一意の識別子を有効化 する] を選択して、メール以外の一意の識別子を設定します。これは、たとえば、一部のユーザーがメール アカウントを持っているわけではない場合や、メール アドレスが一意でない場合に役立ちます。
   2. [ 一意な識別子 ] フィールドにユーザーの一意の識別子を入力する必要があります。これは、サインイン時にユーザーを識別するために UiPath が使用するクレームです。
   3. [ 表示名 ] フィールドに、ログイン時にユーザーを認識するための要求を入力します。
   4. ユーザーの [メール アドレス] フィールドへの入力は任意になります。
   5. [許可されたメール アドレス ドメイン] フィールドは灰色表示され、入力できません。これは、システムが電子メールを一意の識別子として使用しなくなり、このフィールドが無関係になるためです。
   6. 必要に応じて、ID プロバイダーからのそれぞれの要求と UiPath 内の対応する属性を指定して、新しいマッピングを追加します。

9. 属性を設定したら、[未承諾の認証応答を許可] フィールドと [SAML バインドの種類] フィールドを設定します。

   1. 未承諾の認証応答を許可: IdP ダッシュボードから UiPath Platform に移動できるようにする場合は有効化します。
   2. SAML バインドの種類: HTTP ユーザー エージェントを介した SAML 構成の通信方法を選択します。URL パラメーターを使用する場合は [HTTP リダイレクト] を選択し、Base64 で内容がエンコードされた HTML フォームを使用する場合は [HTTP post] を使用します。

10. ご使用の ID プロバイダーで、UiPath がすべての SAML 認証要求に署名することが要求されている場合は、[ 認証要求に署名 ] オプションを選択します。この機能を有効化する必要があるかどうかについては、ID プロバイダーに確認してください。UiPath は署名キーを頻繁に更新します。たとえば、UiPath は署名証明書を 2 週間ごとにローテーションします。[ 認証要求に署名 ] 機能をアクティブ化している場合は、更新されたキーを UiPath のメタデータ URL から継続的にダウンロードし、IdP が定期的に UiPath と同期するようにしてください。

11. [テストして保存] を選択して、連携の設定を終了します。

手順 2.4: 連携が実行中であることを確認する

SAML SSO 連携が正しく機能していることを確認するには、以下の手順を実行します。

1. シークレット ブラウザー ウィンドウを開きます。
2. クラウド組織の URL に移動します。
3. 以下を確認します。
   1. SAML ID プロバイダーでサインインを求められるか。
   2. 正常にサインインできるか。
   3. 既存のユーザー アカウントと一致するメール アドレスでサインインしている場合、適切な権限を持っているか。

手順 2.5.プロビジョニング ルールを設定する (任意)

IdP でクレームを使用すると、クレームをプロビジョニング ルールの条件として活用し、ユーザーが組織にサインインするときに、適切なライセンスとロールを持つ状態で自動的にプロビジョニングされるようにできます。プロビジョニング ルールは、ユーザーがサインインしたときに評価されます。ユーザー アカウントがルールの条件を満たしている場合、そのユーザー アカウントはルールに関連付けられたローカルの UiPath グループに自動的に追加されます。たとえば管理者は、これらの設定を使用して、Automation Users グループにユーザーを直接プロビジョニングするルールを設定できます。例: クレーム=group、リレーションシップ=is、値=Automation User

2.5.1 プロビジョニング グループを設定します。

UiPath でアカウントをグループに追加すると、そのアカウントは、グループに対して定義されたライセンス、ロール、ロボットの設定がある場合はそれらを継承します。

類似するアカウントの種類 (開発者、テスターなど) をグループ化すると、組織へのユーザーのオンボーディング プロセスを効率化できます。必ず、IdP にも類似するアカウントを同じ方法で設定してください。

つまりグループを一度設定すれば、必要に応じてそのグループにアカウントを追加することで設定を複製できます。特定のアカウント グループの設定を変更する必要がある場合は、グループを 1 回更新するだけでグループ内のすべてのアカウントに変更が適用されます。

プロビジョニング ルール用にグループを設定する方法

1. 組織に新しいローカル グループを作成する必要に応じて、新しいグループを作成する代わりに、既存のグループの 1 つを使用できます。
2. (任意かつ ユーザー ライセンス管理 を有効化する必要があります。)グループのアカウントがユーザー ライセンスを必要とする場合は、 グループにライセンスの割り当てルールを設定します。既存のグループを使用している場合は、 グループのライセンス割り当てを確認し、 適切なライセンスが割り当てられていることを確認します。割り当てが適切でない場合は、割り当てを変更するか、新しいグループを作成します。
3. テナント ロールを割り当て、必要に応じてグループのロボットの設定を完了します。手順については、「 ロールをグループに割り当てる 」をご覧ください。既存のグループを使用している場合は、グループに現在割り当てられている ロールを確認して 、グループに追加するアカウントの種類に適切なロールが割り当てられていることを確認します。適切なロールが割り当てられていない場合は、グループに割り当てられたロールを編集するか、新しいグループを作成します。
4. 必要に応じて、グループをフォルダーに追加し、フォルダー ロールを割り当てます。手順については、「フォルダーへのアクセス権を管理する」をご覧ください。

これで、このグループをプロビジョニング ルールで使用できます。

2.5.2. グループのプロビジョニング ルールを作成します

注:

SAML プロビジョニング ルールに関連付けられた要求を SAML アプリケーションで設定し、SAML ペイロードに送信されるようにします。

SAML 連携の設定後かつグループの設定後に以下の手順を実行します。

1. [管理] に移動し、組織を選択して [セキュリティ] を選択します。 組織の [セキュリティ設定] ページが開き、[認証設定] タブが表示されます。

2. [SAML SSO] オプション下の [プロビジョニング ルールを表示] を選択します。[SAML SSO プロビジョニング ルール] ページが開き、既存のルールが表示されます。

3. ページの右上隅にある [ルールを追加] を選択します。 [新しいルールを追加] ページが開きます。

4. [基本情報] の下の [ルール名] フィールドに入力します。必要に応じて [説明] フィールドにも入力します。

5. [条件] の下の [ルールを追加] を選択します。 新しい条件のフィールド行が追加されます。これらのフィールドの組み合わせで、アカウントがグループに追加されるためにサインイン時に満たす必要がある条件を定義します (グループは後で選択)。

   

6. [ クレーム ] フィールドに、IdP に表示されるクレームの名前を入力します。このフィールドでは大文字と小文字が区別されます。

7. [ リレーションシップ] リストから、クレームと値がどのような条件の組み合わせになるか選択します。下表のオプションを使用できます。

   Relationship	条件の要件	例
   次の値に等しい	完全一致、大文字と小文字が区別される	Department is RPA では、 Department クレームの値が RPAである必要があります。たとえば、値が RPADevの場合、この条件は満たされません。このリレーションシップは複数の値を持つクレームに対して機能します。たとえば、 administrator 値と developer 値が Group クレームの下で送信される場合、 Group is administrator は有効なリレーションシップです。
   次の値に等しくない	指定された値以外、大文字と小文字が区別される	Department is not ctrの場合、値が ctrでない限りDepartmentすべてのアカウントがグループに追加されます。部門が Ctr または electrの場合、条件は満たされます。
   次の値を含む	値を含む、完全一致を必要としない、大文字と小文字が区別される	Department contains RPA 、 Department クレームの値に RPAを含める必要があります。たとえば、値が RPADev、 xRPAx、または NewRPAの場合に条件が満たされます。
   次の値を含まない	値を含まない、完全一致を必要としない、大文字と小文字が区別される	Department not contains ctrでは、Department値に ctrが含まれていない限り、すべてのアカウントがグループに追加されます。たとえば、部署が ctr または electrしているアカウントは、グループに追加されません。
   次の値に等しい (大文字と小文字を区別しない)	完全一致、大文字と小文字が区別されない	Department is case insensitive RPA では、 Department クレームの値を rpaにする必要があります。たとえば、値が rpaの場合、条件が満たされます。値が crpaの場合、この条件は満たされません。
   次の値を含む (大文字と小文字を区別しない)	値を含む、完全一致を必要としない、大文字と小文字が区別されない	Department contains case insensitive RPA では、 Department クレームの値に、大文字と小文字の RPAを含める必要があります。たとえば、値が rpa、 cRPA、または rpAの場合に条件が満たされます。

8. [値] フィールドに、条件を満たすために必要な値を入力します。

9. 別の条件を追加する場合は、[ルールを追加] を選択して新しい条件の行を追加します。

   複数の条件を追加した場合、プロビジョニング ルールが適用されるには、すべての条件が満たされる必要があります。たとえば、 Department is RPA (部署 次に値に等しい RPA) と Title is Engineer (役職 次に等しい エンジニア) というルールを定義すると、RPA 部に所属し、かつ役職がエンジニアであるユーザーのみが指定したグループに追加されます。部署が RPA で、タイトルが QA であるアカウントは、グループに追加されません。

10. [グループに割り当て] の下の [グループを追加] ボックスにグループ名を入力し、結果のリストからグループを選択します。必要に応じて、手順を繰り返してさらにグループを追加します。 条件が満たされると、ログイン時にこれらのグループにアカウントが自動的に追加されます。

11. 右下の [保存] を選択してルールを追加します。

ルールが設定されている状態で、ユーザーがログインした際にそのアカウントがルールで指定した条件を満たしていると、そのアカウントがルールにアタッチされたプロビジョニング グループに追加され、UiPath で使用できるようセットアップされます。

サンプル 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>

SAML 属性マッピング

SAML ディレクトリ統合を設定する場合、組織管理者は IdP のどの属性をシステム ユーザー属性にマッピングするかを定義できます。 その後、ユーザーが SAML ディレクトリ統合を介してログインすると、システムは ACS ペイロードに渡された要求を読み取り、その値を対応するシステム属性にマップします。

注:

• IdP は、ACS ペイロードでこれらの要求を渡すように構成する必要があります。
• IdP で設定された属性名が、組織管理者ポータルの属性マッピング設定と一致していることを確認します。

たとえば、これが IdP のユーザー構造である場合、組織管理者は次の属性マッピング設定を設定して、この情報をシステム ユーザー オブジェクトに入力できます。

{
    "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"
}

手順 3: ユーザーを SAML SSO に移行する

必ず UiPath 組織用の組織固有の URL をすべてのユーザーに提供してください。

注:

SAML 連携に切り替えると、Microsoft Entra ID 連携は無効化されます。Microsoft Entra ID グループの割り当ては適用されなくなるため、Microsoft Entra ID から継承された UiPath グループ メンバーシップと権限は考慮されなくなります。

SAML SSO を使用して UiPath にサインインするには、以下の手順を実行します。

• 組織固有の URL に移動します。URL は組織 ID を含み、スラッシュで終る必要があります (例: <AccessURL>/orgID)。
• [ <AccessURL>] に移動し、ログイン ページで [ SSO で続行 ] を選択して、組織固有の URL を指定します。

SAML SSO を使用して UiPath Studio と UiPath Assistant にサインインするには、Assistant を以下のように設定する必要があります。

1. Assistant で [設定] を開き、[Orchestrator への接続] タブを選択します。

2. [サインアウト] を選択します。

3. 接続の種類として [サービス URL] を選択します。

4. [サービス URL] フィールドに組織固有の URL を入力します。

   URL は組織 ID を含んでいて、スラッシュで終わっている必要があります (例: <AccessURL>/orgID)。そうでないと、ユーザーが組織に属していないというメッセージが表示され、接続が失敗します。

5. SAML SSO でサインインし直します。

ステップ4.権限とロボットを設定する

この手順は、連携を有効化したときに、特定の UiPath サービスを使用したことがないため、特定の UiPath サービスでローカル アカウントが設定されていない新しいユーザーにのみ必要となります。

新しいユーザーは、(外部 IdP で使用された) メール アドレスによって UiPath グループに追加できます。ユーザーがグループに割り当てられるか、ユーザーがサインインすると、UiPath のすべてのサービスでユーザーを検索してロールを割り当てられるようになります。

ステップ5.ローカル アカウントの使用を中止する (任意)

警告:

ローカル アカウントを削除する前に、すべてのユーザーが少なくとも 1 回は SSO アカウントでサインインしていることを確認してください。アカウントのリンクは、最初の SSO サインイン時にのみ行われます。SSO を使用してサインインする前にローカル アカウントを削除すると、代わりに新しいディレクトリ ID が作成され、ユーザーはプロジェクトやソリューションなどの以前の作業にアクセスできなくなります。これは元に戻せません。

すべてのユーザーが SAML SSO に移行し、新しいユーザーが設定されたら、管理者アカウント以外のすべてのローカル ユーザー アカウントを削除することをお勧めします。これにより、そのユーザーはローカル アカウントの資格情報でサインインできなくなり、SAML SSO でサインインしなければならなくなります。

ローカル ユーザー アカウントは、そのアイコンに基づいて識別できます。

ローカル アカウントは次のような場合に便利です。

• SAML 連携の問題を管理する場合 (期限切れの証明書の更新など)、または認証設定を変更する場合 - Organization Administrator のロールを持つアカウントの使用をお勧めします。