SSO とユーザープロビジョニング

は、SAML 2.0 またはOpenID 認証プロトコルによるシングルサインオン（SSO）をサポートします。この機能により、これらのプロトコルをサポートするMicrosoft Entra ID（旧 Azure Active Directory）やOkta などのID プロバイダーが、のSSO プラットフォームとして機能します。

概要

SSO を有効にするには、設定ページのセキュリティタブで項目を設定する必要があります。SSO を設定する場合、で作成されたユーザーにはフェデレーション識別子（ID）を付与する必要があります。このフェデレーションID は、のユーザー名とID プロバイダーエンティティを関連付けます。ユーザーがアプリケーションにログインしようとすると、SSO プラットフォームにリダイレクトされ、そこで適切なID の資格情報を入力する必要があります。ジャストインタイム（JIT）ユーザープロビジョニングが有効になっている場合（セキュリティタブからも設定可能）は、ID プロバイダーから受け取った属性（ユーザーの氏名やE メールアドレスなど）に基づいて、ログイン時に新しいユーザーアカウントがに自動的に作成されます。このアイデンティティとアクセス管理（IAM）プロセスは、手動でのアカウント作成の必要性を排除し、オンボーディングを合理化します。詳しくは、ジャストインタイム（JIT）ユーザープロビジョニングを参照してください。 SSO が設定され、ユーザーがID プロバイダーと関連付けるためのフェデレーションID 値を取得したら、次のセクションで説明するとおり、SSO ユーザー管理のための追加の詳細設定はSSO プラットフォームで直接実行する必要があります。

SSO が有効になると、Admin ロールのメンバーでない既存ユーザーは、アカウントにフェデレーションId（後述）が設定されていない限りログインできません。Admin ユーザーは、SSO の設定を再構成する必要がある場合に備え、SSO なしでもログインできます。
現在、は個人ユーザーのみサポートしており、ユーザーグループはサポートしていません。SSO プラットフォームがユーザーグループへのアクセスを提供する場合、グループ内の個々のユーザーは、ログインするためにの設定ページでユーザーとして追加される必要があります。各ユーザーは、ID プロバイダーからのフェデレーションID を参照する必要があります。

次のセクションでは、OpenID Connect およびSAML 2.0 認証プロトコルを使用して、2つのID プロバイダー（Microsoft Entra ID およびOkta）でSSO 構成を設定する方法について説明します。

SSO の設定

このセクションでは、SSO の各設定と、それらがで何を意味するかについて説明します。これらの設定の詳細は、IdP によって異なる場合があります。

OpenID Connect の設定

設定	説明
コールバックURL	コールバックURL は（ではなく）IdP で設定され、ユーザーがIdP に対して認証を実行した後に返される場所を示します。
OAuth クライアントId	IdP で作成されるOAuth アプリケーションに関連付けられたクライアントId。
OAuth クライアントシークレット	IdP で作成されるOAuth アプリケーションに関連付けられたクライアントシークレット。
オーディエンスURI	SSO ログイントークンの意図された受信者。これは、SSO プラットフォームによって生成されたトークンが、での使用を目的としていることを保証します。この値を、SSO プラットフォームでを信頼できるアプリケーションとして識別するURI に設定します（例えば、SSO プラットフォームが用に生成した Application Id など）。複数のURI に対応するには、カンマ区切りリストを指定します。
ディスカバリーURL	SSO プロバイダーから設定をインポートする必要があります。
発行者証明書	IdP がJWT トークンで署名するために使用する証明書の公開部分。これは、要求を受けたIdP によって生成されたトークンのみが受け入れられることを保証するのに役立ちます。
トークン発行者識別子	IdP がJWT トークンを生成するために使用する識別子。は、トークンがこの識別子を含むことを確認するために検証します。これは、要求を受けたIdP によって生成されたトークンのみが受け入れられることを保証するのに役立ちます。
認可URL	ユーザーがIdP を経由して認可を実行する必要があるURL。SSO ユーザーがにログインしようとすると、アプリケーションはユーザーをこのURL にリダイレクトし、そこでSSO プラットフォームの資格情報を入力します。
トークンURL	IdP から安全な認証トークンを取得することができるURL。
ログオフURL	アプリケーションからログアウトした後のユーザーのリダイレクト先を指定します。
デフォルトスコープ	IdP に要求するスコープ（アクセス許可のセット）のスペース区切りのリスト。通常、スコープには、ID 検証を要求するために少なくとも`profile openid` を含める必要があります。
Key Claim	フェデレーションId として扱うIdP からの値。言い換えると、ユーザーをIdP からのユーザー名にマッピングする際にフェデレーションID として使用するクレームを指定します。
トークン署名アルゴリズム	署名されたJWT トークンからどの署名アルゴリズムを受け入れるか。署名のないトークンは認められません。
ジャストインタイム（JIT）プロビジョニング	ユーザーが初めてログインしたときに、に新しいユーザーアカウントを自動的に作成するかどうか。ユーザーの詳細は、クレームで提供された属性に基づきます。
デフォルトロール	JIT プロビジョニング中に作成されたアカウントに割り当てられるロール（Support、Standard、またはAdmin）。デフォルトロールなしを選択した場合は、クレームで指定されたロールが使用されます。

SAML 2.0 の設定

設定	説明
アサーションコンシューマサービス（ACS）URL	ユーザーが正常にログインした後にIdP がSAML 認証応答を送信するアプリケーションのエンドポイント。これは、OpenID のコールバックURL 設定に似ています。
オーディエンスURI	SAML アサーションの送信先となる一意の識別子（通常はアプリケーションのエンティティID）。応答がアプリケーション向けであることを検証するために使用されます。
SAML ディスカバリーURL	認証に使用するIdP を決定するために使用されるエンドポイント。SSO プロバイダーから設定をインポートする必要があります。
発行者証明書	IdP がJWT トークンで署名するために使用する証明書の公開部分。要求を受けたIdP によって生成されたトークンのみが受け入れられることを保証するのに役立ちます。
エンティティID	SAML 認証プロセスでIdP またはサービスプロバイダーを識別するために使用される、グローバルに一意の識別子（多くの場合、URI 形式）。
SSO URL	サービスプロバイダーがユーザーをリダイレクトしてSAML 認証フローを開始するIdP エンドポイント。
ログオフURL	アプリケーションからログアウトした後のユーザーのリダイレクト先を指定します。
ジャストインタイム（JIT）プロビジョニング	ユーザーが初めてログインしたときに、に新しいユーザーアカウントを自動的に作成するかどうか。ユーザーの詳細は、SAML アサーションで提供された属性に基づきます。
デフォルトロール	JIT プロビジョニング中に作成されたアカウントに割り当てられるロール（Support、Standard、またはAdmin）。デフォルトロールなしを選択した場合は、SAML アサーションで指定されたロールが使用されます。

Microsoft Entra ID のSSO 設定

次のセクションでは、OpenID Connect またはSAML 2.0 経由でSSO 用にMicrosoft Entra ID を設定する方法について説明します。

OpenID Connect 設定

Microsoft Entra ID を使用したシングルサインオン（SSO）により、へのアクセスが合理化され、ログイン時にジャストインタイムのプロビジョニングが可能になります。次の手順では、OpenID Connect プロトコルを使用してSSO 用にMicrosoft Entra ID を設定する方法について説明します。

Azure ポータルにログインし、Microsoft Entra ID を開きます。
にログインし、設定 > SSO を選択してシングルサインオン（SSO）設定ダイアログボックスを開きます。
Entra ID > アプリ登録 > 新規登録に移動し、のアプリケーション登録を作成します。プロンプトに従って処理を完了します。
アプリ登録で、リダイレクトURL を、以下に示すようにのシングルサインオン（SSO）設定ダイアログボックスで指定されているコールバックURL 値に設定します。
のシングルサインオン（SSO）設定ダイアログボックスで、次のプロパティを指定します：
1. クライアントID プロパティを、以下に示す新しいアプリ登録にあるアプリケーション（クライアント）Id の値に設定します。
2. クライアントシークレットプロパティを、アプリ登録のクライアントクレデンシャルセクションで作成した新しいクライアントシークレットの値に設定します。
3. ディスカバリーURL を、アプリ登録のエンドポイントページにあるOpenID Connect MetaData document の値に設定します。次に、インポートをクリックして、残りの設定をにインポートします。
で保存およびテストをクリックして、SSO の設定を確認します。で新しいタブが開き、Microsoft アカウントでのサインインを求められます。テストに成功すると、はクレームの詳細とともに成功メッセージを表示します。
（オプション）ユーザーアカウントをフェデレーションId で更新します。
1. ステップ5 のシングルサインオン（SSO）設定ダイアログボックスから、フェデレーションId をコピーします。
2. 設定 > ユーザーに移動します。次に、ユーザーアカウントを見つけて編集をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、保存をクリックして変更を保存し、ダイアログボックスを終了します。

この時点で、OpenID Connect SSO の基本設定が完了し、ユーザーはMicrosoft Entra ID 経由でにログインできるようになりました。

SAML 2.0 設定

SAML ベースのシングルサインオン（SSO）により、ユーザーは組織のID プロバイダーを通じてシームレスに認証できるため、ログイン時にジャストインタイムプロビジョニングが可能になります。次の手順では、SAML 2.0 プロトコルを使用してSSO 用にMicrosoft Entra ID を設定する方法について説明します。

Azure ポータルにログインしてMicrosoft Entra ID を開き、エンタープライズアプリケーションページに移動します。
新しいアプリケーション > 独自のアプリケーションを作成するを選択します。独自のアプリケーションを作成するダイアログボックスで：
1. アプリケーションの名前を入力します（例：CData Arc）。
2. アプリケーションでどのような操作を行いたいですか？ の下にあるオプションから、アプリケーションで実行したい操作を指定します。
3. 作成をクリックします。
新規作成したアプリケーションで、シングルサインオンの設定を選択します。
サインオン方式としてSAML を選択します。
にログインし、設定 > SSO を選択します。SSO タブで、シングルサインオン（SSO）設定セクションの設定をクリックします。このアクションにより、シングルサインオン（SSO）設定ダイアログボックスが開きます。
SAML 2.0 を選択します。これを選択すると、アサーションコンシューマーサービス（ACS）URL とオーディエンスURI が表示されます。
このダイアログボックスは、手順の後半で再び必要になるので開いたままにしておきます。
Entra ID で、応答URL（アサーションコンシューマーサービスURL） をのアサーションコンシューマーサービス（ACS）URL 値に設定します。次に、Entra ID の識別子（エンティティID） を、のオーディエンスURI 値に設定します。
ID プロバイダーによるサインオンを使用する場合は、サインオンURL テキストボックスを空のままにしておきます。
のシングルサインオン（SSO）設定ダイアログボックスで、ディスカバリーURL を、Entra ID にあるApp Federation Metadata URL 値に設定します。次に、インポートをクリックして、残りの設定をにインポートします。
で保存およびテストをクリックして、SSO の設定を確認します。で新しいタブが開き、Microsoft アカウントでのサインインを求められます。テストに成功すると、はクレームの詳細とともに成功メッセージを表示します。
.NET 版を使用している場合は、テストに影響する可能性のある.NET の問題については、.NET におけるSAML 2.0 設定の既知の問題を参照してください。
（オプション）ユーザーアカウントをフェデレーションId で更新します。
1. ステップ9 のシングルサインオン（SSO）設定ダイアログボックスからフェデレーションId をコピーします。
2. 設定 > ユーザーに移動します。次に、ユーザーアカウントを見つけて編集をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、保存をクリックして変更を保存し、ダイアログボックスを終了します。

この時点で、SAML SSO の基本設定が完了し、ユーザーはMicrosoft Entra ID 経由でにログインできるようになりました。

Okta のSSO 設定

次のセクションでは、OpenID Connect またはSAML 2.0 経由でSSO 用にOkta を設定する方法について説明します。

OpenID Connect 設定

Okta を使用したシングルサインオン（SSO）により、へのアクセスが合理化され、ログイン時にジャストインタイムのプロビジョニングが可能になります。次の手順では、OpenID Connect プロトコルを使用してSSO 用にOkta を設定する方法について説明します。

Okta 管理コンソールにログインし、Applications > Applications > Create App Integration を選択します。
新しいアプリ統合の作成ダイアログボックスで、サインイン方式にOIDC - OpenID Connect を、アプリケーションの種類にWeb アプリケーションを選択します。続いて、次へをクリックします。
にログインし、設定 > SSO を選択してシングルサインオン（SSO）設定ダイアログボックスを開きます。
Okta で、リダイレクトURI を、以下に示すようにのシングルサインオン（SSO）設定ダイアログボックスで指定されているコールバックURL 値に設定します。続いて、次へをクリックしてアプリケーションを作成します。
以下のように、発行者URL を検索してコピーします。
1. Okta 管理コンソールで、アプリケーションのSign-On タブをクリックします。
2. OpenID Connect ID Token セクションまでスクロールします。
3. Issuer フィールドからURL をコピーします。
認可サーバー経由でサインインする場合は、その特定のサーバーの発行者URL を取得する必要があります。Okta 管理コンソールで、左側のナビゲーションペインのSecurity をクリックし、API を選択してAuthorization Servers リストを表示します。認可サーバーを見つけて、Issuer フィールドからURL をコピーします。
のシングルサインオン（SSO）設定ダイアログボックスで、次のプロパティを指定します：
1. クライアントID およびクライアントシークレットプロパティを、Okta の全般タブにある対応する値に設定します。
2. ディスカバリーURL を、先ほどコピーした発行者URL に設定し、OpenID Connect ディスカバリーエンドポイント（.well-known/openid-configuration）を追加します。例： https://MyOrganization.okta.com/.well-known/openid-configuration 次に、インポートをクリックして、残りの設定をにインポートします。
で保存およびテストをクリックして、SSO の設定を確認します。で新しいタブが開き、Okta アカウントでのサインインを求められます。テストに成功すると、はクレームの詳細とともに成功メッセージを表示します。
（オプション）ユーザーアカウントをフェデレーションId で更新します。
1. ステップ6 のシングルサインオン（SSO）設定ダイアログボックスから、フェデレーションId をコピーします。
2. 設定 > ユーザーに移動します。次に、ユーザーアカウントを見つけて編集をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、保存をクリックして変更を保存し、ダイアログボックスを終了します。

この時点で、OpenID Connect SSO の基本設定が完了し、ユーザーはOkta 経由でにログインできるようになりました。

SAML 2.0 設定

SAML ベースのシングルサインオン（SSO）により、ユーザーは組織のID プロバイダーを通じてシームレスに認証できるため、ログイン時にジャストインタイムプロビジョニングが可能になります。次の手順では、SAML 2.0 プロトコルを使用してSSO 用にOkta を設定する方法について説明します。

Okta 管理コンソールにログインし、Applications > Create App Integration を選択します。この手順により、新しいアプリ統合の作成ダイアログボックスが開きます。
サインイン方式としてSAML 2.0 を選択します。続いて、次へをクリックするとSAML 統合の作成ダイアログボックスが開きます。
アプリ名テキストボックスに、アプリケーションのわかりやすい名前（例えば、）を入力します。必要に応じて、アプリケーションのロゴを追加することもできます。続いて、次へをクリックします。
アプリケーションで、設定ページのSSOタブをクリックします。そのタブ上で、シングルサインオン（SSO）設定セクションの設定をクリックします。このアクションにより、シングルサインオン（SSO）設定ダイアログボックスが開きます。
SAML 2.0 を選択します。これを選択すると、アサーションコンシューマーサービス（ACS）URL とオーディエンスURI が表示されます。
このダイアログボックスは、手順の後半で再び必要になるので開いたままにしておきます。
Okta で、のアサーションコンシューマーサービス（ACS）URL 値を、シングルサインオンURL テキストボックスに入力します。次に、のオーディエンスURI 値をオーディエンスURI（SP エンティティID） テキストボックスに入力します。残りのOkta フィールドは、デフォルト設定のままにしておきます。
で、ディスカバリーURL を、登録済みのOkta 組織のドメインに/oauth2/default/.well-known/openid-configuration を付けたURL に設定します。例： https://trial-1234567.okta.com/oauth2/default/.well-known/openid-configuration 次に、インポートをクリックして、残りの設定をにインポートします。
で保存およびテストをクリックして、SSO の設定を確認します。で新しいタブが開き、Okta アカウントでのサインインを求められます。テストに成功すると、はクレームの詳細とともに成功メッセージを表示します。
.NET 版を使用している場合は、テストに影響する可能性のある.NET の問題については、.NET におけるSAML 2.0 設定の既知の問題を参照してください。
（オプション）ユーザーアカウントをフェデレーションId で更新します。
1. ステップ8 のシングルサインオン（SSO）設定ダイアログボックスから、フェデレーションId をコピーします。
2. 設定 > ユーザーに移動します。次に、ユーザーアカウントを見つけて編集をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、保存をクリックして変更を保存し、ダイアログボックスを終了します。

この時点で、SAML SSO の基本設定が完了し、Okta 経由でにログインできるようになりました。

ジャストインタイム（JIT）ユーザープロビジョニング

前述のとおり、ジャストインタイムユーザープロビジョニング により、はID プロバイダーから提供された情報を使用して、初回ログイン時にユーザーアカウントを自動的に作成および管理できるようになります。JIT プロビジョニングは、ユーザーが初めてID プロバイダーを通じてにアクセスし、アプリケーションがユーザーのID を確認する安全なメッセージを受信する場合に特に便利です。作成されたアカウントには、SSO 設定で指定されたデフォルトのロールが割り当てられます。この機能により、ユーザーのオンボーディングが合理化され、アカウントの詳細がアイデンティティクレームと一致することが保証されます。ユーザーがSAML またはOpenID Connect を使用してにログインすると、はフェデレーションId を介してそのユーザーを検索します。

ユーザーが存在しない場合、は認証クレームで提供される情報を使用して新しいユーザーを自動的に作成します。
ユーザーが存在する場合、は、クレーム値と一致しない場合にユーザーのユーザー名とE メールアドレスを更新します。

ID プロバイダーにおける要件とマッピング

ID プロバイダーの要件は、SAML 2.0 またはOpenID Connect のどちらを使用するかによって異なります。このセクションでは、各認証方式のクレーム要件について説明します。 OpenID Connect

デフォルトでは、サブコントロールはユーザーのロールにマッピングされ、クレームはフェデレーションId にマッピングされます。オプションとして、admin ユーザーは、でKey Claim プロパティを設定することにより、別のフィールド（例えばoid）を使用できます。
Email クレームは、のEmail Address にマッピングされます。
preferred_username クレームは、のname にマッピングされます。

SAML 2.0

NameID とEmail クレームは必須です。
（オプション）Name クレームを追加できます。これは、のUsername にマッピングされます。
（オプション）Role クレームを追加できます。これは、ユーザーのロールを制御します。

Arc でのJIT 設定

でJIT プロビジョニングを有効化および設定するには：

次の手順でJIT プロビジョニングを有効にします：
1. で設定 > SSO を選択します。
2. タブレットと鉛筆アイコンをクリックし、ジャストインタイム（JIT）プロビジョニングダイアログボックスを開きます。
3. JIT プロビジョニングカテゴリの下で有効化を選択します。
4. （オプション）デフォルトロールリストからロールを選択して、デフォルトのロールを設定します。
5. 保存をクリックして選択内容を保存し、ダイアログボックスを終了します。

ユーザーがログインすると、は次の順序でロールを調整します：

クレームにロールが含まれている場合、はそのロールを検索してユーザーアカウントを更新します。
ロールクレームが存在しないか無効な場合、は設定されたデフォルトロールを使用します。これは、ID プロバイダーによってクレームでロールが割り当てられない限り、JIT を使用してデフォルトロールで作成されたユーザーのロールは、のadmin ユーザーによって上書きできないことを意味します。
デフォルトロールが設定されていない場合、ユーザーアカウントにはロールがないため、Admin ユーザーが手動でユーザーのロールを更新する必要があります。

.NET におけるSAML 2.0 設定の既知の問題

.NET 版でSAML 2.0 を設定する場合、保存およびテストボタンをクリックすると認証が成功したように見えても、その後にエラーが表示されます。これは既知の.NET プラットフォームの問題であり、実際のSAML ログインには影響しません。 SameSite クッキーの制限を緩和すると、クロスサイトリクエストフォージェリ（CSRF）攻撃にさらされるリスクが高まる可能性があるため、これらの設定はデフォルトではWeb.Config に含まれていません。この回避策を有効にすると、より厳格なデフォルトのセキュリティと引き換えに、.NET の特定のSAML 2.0 ログインフローとの互換性が得られます。この問題を回避するには、次の手順に従います：

次の内容をWeb.Config ファイルに追加します（デフォルトでは、ファイルはC:\Program Files\CData\CData Arc\www にあります）：
- authentication mode="forms" 内のcookieSameSite="None" requireSSL="true"
- httpCookies 内のsameSite="None" requireSSL="true"
- sessionState 内のcookieSameSite="None" cookieless="UseCookies"
HTTPS でArc を再起動します。

このサンプルのWeb.Config ファイルは、必要な更新内容を示しています：

<configuration>
  <system.web>
    <!--  ... -->
    <authentication mode="Forms">
      <forms name="Arc" path="/" loginUrl="~/login.rst" protection="All" timeout="30" defaultUrl="~/default.rst" cookieSameSite="None" requireSSL="true">
      </forms>
    </authentication>
    <!--  ... -->
    <httpCookies httpOnlyCookies="true" sameSite="None" requireSSL="true"/>
    <sessionState timeout="10" cookieSameSite="None" cookieless="UseCookies" />
    <!--  ... -->
  </system.web>
</configuration>

はじめに

フロー

EDI トレーディングパートナー管理コンソール

コネクタ

マッピング

API と自動化

ハウツーガイド

スクリプティング

ソフトウェアライセンスとサードパーティ著作権

SSO とユーザープロビジョニング

概要