- 基本情報
- データのセキュリティとコンプライアンス
- 組織
- 認証とセキュリティ
- ライセンス
- テナントとサービス
- アカウントとロール
- AI Trust Layer
- 外部アプリケーション
- 通知
- ログ
- トラブルシューティング
- Automation Cloud™ に移行する
SAML 連携を設定する
この機能は、Enterprise ライセンス プランで利用できます。
Automation Cloud で SAML 設定を使用することで、認証のセキュリティと効率の両方が強化されます。UiPath のシステムでは、SAML を使用してセキュリティで保護されたアクセス トークンによるシングル サインオン (SSO) を実現しています。これにより、UiPath Platform は SAML 2.0 標準を使用する任意の ID プロバイダー (IdP) に接続できます。
さらに、SAML構成にはシングルログアウト(SLO)機能が含まれており、IdPで統合されたすべてのアプリケーション間での同時ログアウトが可能です。
SAML 連携は、既存のユーザーの混乱を招くことなく、段階的に導入することができます。
ネイティブの Azure Active Directory との連携から SAML との連携に切り替える
認証に AAD を使用している場合は、より豊富な機能を使用できるネイティブの AAD 統合を使用することをお勧めします。
SAML 連携に切り替える場合は、アクセス スキーマを完全に再作成する必要がないように、ディレクトリ グループを介して行われるロールの割り当てを、ディレクトリ アカウントへの直接ロールの割り当てに手動で置き換える必要があります。
-
ID プロバイダーからの暗号化された SAML アサーションはサポートされていません。
-
ID プロバイダーからユーザーおよびグループを検索することはできません。 検索できるのは、プロビジョニングされたディレクトリ ユーザーのみです。
-
組織レベルではディレクトリ ユーザーを表示できません。 組織レベルで表示されるのはローカル ユーザーのみです。 ディレクトリ ユーザーは Just-In-Time プロビジョニングでは追加されるため、 Automation Cloud の [ アカウントとグループ] ページには表示されません。
-
SAML 連携を使用してサインインするディレクトリ ユーザーは、ユーザー キーを使用して API 要求を認可できる API アクセス情報を表示できません。
SAML 連携を設定するには、以下が必要です。
- Enterprise ライセンス プランの Automation Cloud 組織。
-
Automation Cloud の組織とサードパーティ ID プロバイダーの両方に対する管理者権限。ID プロバイダーの管理者権限がない場合は、管理者と協力してセットアップ プロセスを完了できます。
-
UiPath® Studio および UiPath Assistant のバージョン 2020.10.3 以降 (推奨されるデプロイを使用するよう設定できるようにするため)。
組織でメール アドレスを再利用している場合は、SAML 連携を設定する前に、非アクティブなユーザー アカウントをすべて削除することが重要です。
連携を有効化すると、 Automation Cloud に存在するローカル アカウントを、同じメール アドレスを使用する外部 ID プロバイダーのディレクトリ アカウントにリンクできます。 このアカウントのリンクは、メール アドレスを持つディレクトリ アカウント ユーザーが初めてサインインするときに行われます。 ID プロバイダーの ID はローカル アカウントからすべてのロールを継承するため、移行はシームレスに行われます。 このため、 Automation Cloud に非アクティブなローカル アカウントが存在すると、ローカル アカウントとディレクトリ アカウントが一致せず、意図しない権限の昇格につながるリスクがあります。
非アクティブなユーザー アカウントを削除するには、以下の手順を実行します。
次に、 Automation Cloud と ID プロバイダー (IdP) の両方を連携用に設定する必要があります。
- ページの上部には、ID プロバイダーの構成に必要な UiPath の情報 ( メタデータ URL、 アサーション コンシューマー サービス URL、 エンティティ ID) が表示されます。 ID プロバイダーを設定するために、それらをコピーして保存します。重要: ID プロバイダーの構成プロセスの一環として、UiPath のメタデータ URL を使用することを強くお勧めします。こうすると、UiPath が署名証明書のローテーションを開始した場合に常に自動更新できるため、プラットフォームを中断なく動作させることができます。
このブラウザー タブは、後で使用するために開いたままにします。
SAML 2.0 標準を使用する任意のサードパーティの ID プロバイダー (IdP) に接続できます。設定は選択した IdP によって異なることがありますが、Okta または PingOne を使用する場合の設定は検証済みです。連携を設定する際の参考にしてください。
他の ID プロバイダーについては、それぞれの連携に関するドキュメントに従ってください。
Automation Cloud を、ID プロバイダーを認識するサービス プロバイダーとして有効化するには、以下の手順を実行します。
- [ID プロバイダーを設定] ページの 2 番目のセクションに、Automation Cloud で ID プロバイダーを設定するために必要なフィールドが表示されます。[ メタデータ URL ] フィールドに、ID プロバイダーのメタデータ URL を入力します。 これにより、 Automation Cloud は ID プロバイダーから定期的にデータを取得して更新できるようになり、SAML 構成プロセスを長期的に効率化できます。大事な： SAML の構成時に メタデータ URL を使用することを強くお勧めします。 これにより、UiPath は ID プロバイダーからデータを定期的に取得して更新できるため、長期的には SAML 構成プロセスが効率化されます。
- 複数の証明書を手動で入力するには、証明書の開始と終了のインジケーターで囲み、改行文字で区切って 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----- - 右下隅の [ 次へ ] をクリックして次のステップに進みます。 [ Map attributes & complete ] タブが表示されます。 「クレーム」と呼ばれる属性のマッピングは、ID プロバイダーと Automation Cloud の間でユーザーの詳細をリンクします。 これにより、メールやユーザー名などのユーザーデータが両方のシステムで確実に一致します。
SAML SSO 連携が正しく機能していることを確認するには、以下の手順を実行します。
- シークレット ブラウザー ウィンドウを開きます。
- Automation Cloud の組織の URL に移動します。
- 以下を確認します。
- SAML ID プロバイダーでサインインを求められるか。
- 正常にサインインできるか。
- 既存のユーザー アカウントと一致するメール アドレスでサインインしている場合、適切な権限を持っているか。
IdP でクレームを使用すると、クレームをプロビジョニング ルールの条件として活用し、ユーザーが Automation Cloud にサインインするときに、適切なライセンスとロールを持つ状態で自動的にプロビジョニングされるようにできます。 プロビジョニング ルールは、ユーザーがサインインしたときに評価されます。 ユーザー アカウントがルールの条件を満たしている場合、そのユーザー アカウントはルールに関連付けられたローカルの UiPath グループに自動的に追加されます。 たとえば管理者は、これらの設定を使用して、Automation Users グループにユーザーを直接プロビジョニングするルールを設定できます。たとえば、 クレーム=グループ、 リレーションシップ=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>-
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 連携に切り替えると、Azure AD との連携は無効化されます。 Azure AD のグループ割り当ては適用されなくなったため、 Automation Cloud のグループ メンバーシップと Azure AD から継承された権限は尊重されなくなります。
SAML SSO を使用して Automation Cloud にサインインするには、以下の手順を実行します。
- 組織固有の URL に移動します。URL は組織 ID を含み、スラッシュで終る必要があります (例:
https://cloud.uipath.com/orgID)。 - https://cloud.uipath.com に移動します。ログイン ページで [SSO で続行] を選択し、組織固有の URL を指定します。
SAML SSO を使用して UiPath Studio と UiPath Assistant にサインインするには、Assistant を以下のように設定する必要があります。
この設定は、 これまで Automation Cloud を使用したことがなく、そのため、連携が有効化された際に Automation Cloud でローカル アカウントを設定していなかった新規ユーザーにのみ必要です。
メール アドレス (外部 IdP で使用) で新しいユーザーを Automation Cloud グループに追加できます。 ユーザーがグループに割り当てられたかサインインすると、すべての UiPath サービスでロールの割り当てを検索できるようになります。
すべてのユーザーが SAML SSO に移行し、新しいユーザーが設定されたら、管理者アカウント以外のすべてのローカル ユーザー アカウントを削除することをお勧めします。これにより、そのユーザーはローカル アカウントの資格情報でサインインできなくなり、SAML SSO でサインインしなければならなくなります。
ローカル ユーザー アカウントは、そのアイコンに基づいて識別できます。
ローカル アカウントは次のような場合に便利です。
-
SAML 連携の問題を管理する場合 (期限切れの証明書の更新など)、または認証設定を変更する場合 - Organization Administrator のロールを持つアカウントの使用をお勧めします。
-
SAML SSO アカウントでは [API アクセス] 機能 ([管理] > [テナント] ページ) にアクセスできないために、API アクセス トークンを利用して要求の認可を行うプロセスの場合。代替策として、OAuth による認可に切り替えれば、API アクセスの情報は不要になります。
