認証モデルについて

ローカル アカウント モデル (招待ベース)

ローカル ユーザー アカウントは各ユーザーのアカウントを表し、UiPath Platform の内部にあります。

ローカル アカウント モデルは、自己完結型の認証アプローチを提供します。新規ユーザーが参加するには、組織管理者からの招待が必要です。プラットフォーム内のユーザー管理を完全に制御する必要がある場合に適しています。

注: このモデルは、ディレクトリ アカウント モデルに対応しています。ディレクトリ モデルを使用する場合でも、引き続き招待ベースのモデルを使用してユーザーを作成できます。

組織の設定では、ユーザーが使用できる認証方法を完全に制御できます。

• 利用可能なすべての認証方法 (Google、Microsoft、基本認証) を使用できるようにして柔軟性を最大限に高めるには、[利用可能なすべての方法] オプションを選択します。

• 認証方法を Google のみに制限するには、[Google サインイン] オプションを選択します。

• 認証方法を Microsoft のみに制限するには、[Microsoft サインイン] オプションを選択します。

Google、Microsoft、LinkedIn、または個人の電子メールによる認証

このモデルは、既定ですべての新しい組織に適用されます。使いやすく、迅速に設定でき、ユーザーにとっては便利です。

ユーザーを作成するためのプロセスは次のとおりです。

1. 組織管理者は、ユーザーのメール アドレスを入手してから、そのアドレスを使用して各ユーザーを招待し、組織に参加させる必要があります。この作業は、一括して行えます。

2. 招待された各従業員は、招待メールに記載されたリンクにアクセスして招待を受諾し、UiPath のユーザー アカウントを作成します。以下に、その方法を示します。

   • 招待されたメール アドレスをユーザー名として使用し、パスワードを作成します。

   • 既に所有している Microsoft (個人、Azure AD リンク済み、Office 365) または Google (個人、Google Workspace) のアカウント、あるいは個人の LinkedIn のアカウントを使用して、UiPath のユーザー アカウントにサインインします (またはフェデレーション方式でサインインします)。

     これらいずれかのプロバイダーのアカウントを使用できることで、余計なパスワードを覚えずに済むため、ユーザーにとっては便利です。また、組織が所有する Azure AD または Google Workspace のアカウントを使用することで、組織のサインイン ポリシーを徹底することができます。

     
     

     

     
     

Google または Microsoft のみによる認証

このモデルでは、招待ベースのモデルと同じ方法でユーザーを作成します。メール アドレスに招待を発行し、ユーザーは UiPath アカウントを作成する必要があります。違いは、以下のいずれかを使用したサインインの適用を選択できることです。

• Google または
• Microsoft

ユーザーには、すべてのサインイン オプションが表示されるのではなく、管理者が選択したサインイン オプションだけが表示されます。

たとえば、Microsoft でのサインインを適用する場合にユーザーに表示される情報は以下のようになります。

ユーザーは引き続き、自分の UiPath アカウントを使用してサインインします。アカウントには、招待メールの送信先のメール アドレスを使用する必要があります。

注: 組織の外部アプリケーションを認証した場合、他のプロバイダーの使用中に生成されたトークンは引き続き有効ですが、新しいトークンは適用されたサインイン ポリシーに従います。

ディレクトリ アカウント モデル

ディレクトリ アカウント モデルは、UiPath Platform と連携するサードパーティ ディレクトリに依存しています。これにより、所属する企業内で使用されている ID スキーマをそのまま UiPath で使用できます。

• Azure Active Directory: Microsoft Azure または Office 365 のサブスクリプションを契約している場合は、Azure を UiPath Platform と連携させて、UiPath 内で Azure Active Directory の既存のユーザーとグループを使用できます。
• SAML 2.0: UiPath Platform と選択した ID プロバイダー (IdP) を連携できます。これにより、ユーザーは IdP に登録済みのアカウントを使用して、シングル サインオン (SSO) で UiPath に接続できます。

ディレクトリ ユーザー アカウントは UiPath の外部のディレクトリ内で作成・管理されます。ディレクトリ アカウントは UiPath Platform で参照先としてのみ利用され、ユーザーの ID として使用されます。

注:

招待ベースのモデルとの併用

引き続き、招待ベースのモデルのすべての機能をディレクトリ モデルと組み合わせて使用できます。ただし、ディレクトリ モデルのメリットを最大限に活かすには、統合されたディレクトリからの一元化されたアカウント管理のみを使用することをお勧めします。

Azure Active Directory

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

Azure Active Directory (Azure AD) との連携により、組織のユーザーやアクセスの管理における拡張性がもたらされ、従業員が使用する社内アプリケーションのすべてにわたってコンプライアンスを確保できるようになります。組織が Azure AD または Office 365 を使用している場合は、組織を Azure AD のテナントに直接接続できるため、以下の機能を使用できます。

• ユーザーの自動オンボードとシームレスな移行

  • UiPath Platform のサービスの権限を割り当てるときに、Azure AD のすべてのユーザーとグループをそのまま使用できます。組織のディレクトリで Azure AD ユーザーを招待したり管理したりする必要はありません。
  • 社内のユーザー名がメール アドレスとは異なるユーザーでもシングル サインオンが可能です。これは、招待ベースのモデルでは不可能なことです。
  • ローカルの UiPath アカウントを持つすべての既存ユーザーの権限は、接続先の Azure AD アカウントに自動的に移行されます。

• サインインの簡素化

  • ユーザーは組織にアクセスするために、招待を受諾したり UiPath のユーザー アカウントを作成したりする必要がありません。Enterprise SSO オプションを選択するか、組織固有の URL を使用することで、Azure AD のアカウントでサインインできます。ユーザーがすでに Azure AD または Office 365 にサインインしている場合は、自動的にサインインされます。
  • UiPath Assistant と Studio のバージョン 20.10.3 以降では、カスタムの Orchestrator URL を使用するよう事前に設定しておくことで、同様のシームレスな接続が可能となります。

• 既存の Azure AD グループによるスケーラブルなガバナンスとアクセス管理

  • Azure AD のセキュリティ グループまたは Office 365 のグループ (すなわち、ディレクトリ グループ) を使用することで、大規模な権限管理に既存の組織構造を活用できます。それにより、ユーザーごとにサービス内の権限を設定する必要がなくなります。
  • 複数のディレクトリ グループをまとめて管理する必要がある場合は、それらを 1 つのグループに統合できます。

  • アクセスの監査は簡単です。UiPath Platform のすべてのサービスの権限を Azure AD グループを使用して設定した後は、Azure AD グループ メンバーシップに関連付けられた、既存の検証プロセスを使用できるようになります。

注:

Azure AD モデルを使用する場合、[API アクセス] オプション ([管理] > テナント) は利用できません。

[API アクセス] ウィンドウの情報を使用して UiPath サービスへの API 呼び出しを認証するプロセスがある場合は、認可に OAuth を使用するように切り替える必要があります。そうすれば、API アクセスからの情報が不要になります。

OAuth を使用するには、外部アプリケーションを UiPath Platform に登録する必要があります。

SAML 2.0

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

このモデルでは、選択した ID プロバイダー (IdP) に UiPath Platform を接続できるため、以下が可能になります。

• ユーザーはシングル サインオン (SSO) を利用できます。
• ID を再作成することなく、UiPath Platform でディレクトリから既存のアカウントを管理できます。

UiPath Platform は、SAML 2.0 標準を使用する任意の外部 ID プロバイダーに接続できます。

メリット

• UiPath Platform へのユーザーの自動オンボーディング: SAML 連携がアクティブな場合、外部 ID プロバイダーのすべてのユーザーは、基本権限で UiPath 組織にサインインすることが許可されます。つまり、次のようになります。

  • ユーザーは、IdP で定義された既存の企業アカウントを使用して、SSO で UiPath 組織にサインインできます。
  • それらのユーザーは、追加の設定なしに Everyone ユーザー グループのメンバーとなり、既定で User 組織ロールが付与されます。UiPath Platform を利用できるようにするには、ユーザーのロールに適したロールとライセンスが必要です。

  • アクセスを一部のユーザーのみに制限する必要がある場合は、ID プロバイダーで UiPath Platform へのアクセスを許可するユーザーのセットを定義できます。

• ユーザーの管理: ユーザーは、グループに直接割り当てることで追加できます。それには、ユーザーをグループに追加するときに、ユーザーのメール アドレスを入力します。

  通常、組織管理者は [管理] > [アカウントとグループ] > [ユーザー] タブでローカル アカウントを管理します。ですが、UiPath のエコシステムでは SAML ユーザーはディレクトリ アカウントであるため、このページには表示されません。

  ユーザーがグループに追加されるか、1 回でもサインインすると (自動的に Everyone グループに追加されます)、UiPath のすべてのサービスで、ユーザーを検索してロールまたはライセンスを直接割り当てられるようになります。

• 属性マッピング: UiPath Automation Hub を使用する場合は、カスタム属性マッピングを定義して、ID プロバイダーの属性を UiPath Platform に反映できます。たとえば、アカウントが Automation Hub に初めて追加されたときに、ユーザーの姓、名、メール アドレス、役職、部門はすでに入力されています。

認証の仕組み

ユーザーの ID は、組織ディレクトリに基づいて検証されます。その後、ロールやグループによって割り当てられたユーザー権限に基づき、各ユーザーは一式の資格情報だけですべての UiPath クラウド サービスにアクセスできます。下の図は、2 つの ID モデルの概要と、これらのモデルが各種ユーザー ID とどのように連携し、またどのようにフェデレーションが実現されるかを示します。招待ベースのモデルの場合、ID の管理は組織ディレクトリ内のユーザー参照に対して行いますが、ユーザーは引き続きアカウントによって管理されます。ただし、Azure Active Directory (Azure AD) と連携している場合は、Azure AD のテナント ディレクトリの内容を確認するだけの簡単な作業になります (下の図の橙色の矢印部分)。

モデルの比較

組織の認証設定を選択するときに考慮する必要のあることは以下のとおりです。

要素	招待ベース	オプションが適用される招待ベース	Azure Active Directory	SAML
Community ライセンス	利用可能	利用可能	利用できません。	利用できません。
Enterprise ライセンス	利用可能	利用可能	利用可能	利用可能
ローカル アカウントのサポート (UiPath アカウント)	利用可能	利用可能	利用可能	利用可能
ディレクトリ アカウントのサポート	利用できません。	利用できません。	利用可能	利用可能
ユーザー アカウントの管理	Automation Cloud の組織管理者	Automation Cloud の組織管理者	Azure AD 管理者	ID プロバイダーの管理者
ユーザー アクセスの管理	Automation Cloud の組織管理者	Automation Cloud の組織管理者	Automation Cloud のユーザー管理は、Azure AD に完全に委任可能	Automation Cloud の組織管理者
シングル サインオン	利用可能 (Google、Microsoft、または LinkedIn を使用)	利用可能 (Google または Microsoft を使用)	利用可能 (Azure AD アカウントを使用)	利用可能 (IdP アカウントを使用)
複雑なパスワードのポリシーを適用	利用できません。	利用可能 (IdP から適用される場合)	利用可能 (AAD から適用される場合)	利用可能 (IdP から適用される場合)
多要素認証	利用できません。	利用可能 (IdP から適用される場合)	利用可能 (AAD から適用される場合)	利用可能 (IdP から適用される場合)
所属企業の既存の ID を再利用	利用できません。	利用できません。	利用可能	利用可能
大規模なユーザー オンボード	利用不可 (すべてのユーザーを招待する必要あり)	利用不可 (すべてのユーザーを招待する必要あり)	利用可能 (Just-In-Time アカウントのプロビジョニング)	利用可能 (Just-In-Time アカウントのプロビジョニング)
企業外のコラボレーターのアクセス	利用可能 (招待を通じて)	利用可能 (適用される IdP のアカウントの招待を通じて)	利用可能	利用可能 (IdP によって許可されている場合)
企業ネットワーク内からのアクセスを制限	利用できません。	利用できません。	利用可能	利用可能 (IdP から適用される場合)
アクセスを信頼できるデバイスに制限	利用できません。	利用できません。	利用可能	利用可能 (IdP から適用される場合)

ID ディレクトリを再利用する

以下の表は、所属企業がすでにディレクトリを使用して従業員のアカウントを管理している場合に、より便利な認証オプションを決定する際に役立ちます。

要素	招待ベース	オプションが適用される招待ベース	Azure Active Directory	SAML
ID プロバイダーとして Google Workspace を既に使用している場合	ユーザーには UiPath アカウントが必要。ただし、SSO も可能	ユーザーに UiPath アカウントが必要。ただし、Google を使用して SSO も適用可能	N/A	N/A
ID プロバイダーと組み合わせて Office 365 を既に使用している場合	ユーザーに UiPath アカウントが必要	ユーザーに UiPath アカウントが必要	既存のユーザー アカウントに Automation Cloud へのアクセス権を付与可能	既存のユーザー アカウントに Automation Cloud へのアクセス権を付与可能
ID プロバイダーとして Azure AD を既に使用している場合	ユーザーに UiPath アカウントが必要	ユーザーに UiPath アカウントが必要	既存のユーザー アカウントに Automation Cloud へのアクセス権を付与可能	SAML 連携の代わりに AAD 連携を使用することをお勧めします。
別の ID プロバイダーを既に使用している場合	ユーザーに UiPath アカウントが必要	ユーザーに UiPath アカウントが必要	既存のユーザー アカウントに Automation Cloud へのアクセス権を付与可能	既存のユーザー アカウントに Automation Cloud へのアクセス権を付与可能