Okta の Express Configuration

Auth0 および Okta Integration Network（OIN）で Express Configuration を設定する方法について説明します。

Okta Integration Network (OIN) は SaaS アプリケーションのカタログで、Okta は OpenID Connect を使用したシングルサインオン (SSO) の有効化、SCIM による自動ユーザープロビジョニング、Universal Logout に向けた簡易セットアップ機能を提供しています。Okta 管理者は、Okta Admin Console を使用して、Okta テナント内でこれらの統合を設定します。

Express Configuration を使用すると、エンタープライズ顧客は、プロトコル固有の設定値をコピー&ペーストすることなく、SaaS アプリケーションとの ID 統合を安全に構成できます。

Express Configuration には、Okta 管理者と SaaS アプリケーション開発者にとって次の利点があります。

• Okta と Auth0 の間で設定情報のやり取りを自動化することで、アプリケーションインスタンスのセットアップにかかる時間を短縮します。
• OAuth 2.0 の同意フローを使用して、機密性の高い設定データを安全かつ適切な認可のもとで共有し、認証情報や設定に関する潜在的なエラーを減らします。
• 統合のデプロイプロセスを簡素化して標準化します。自動化されたワークフローにより、複数の顧客や環境にまたがるアプリケーション統合の一貫した反復可能なデプロイが可能になり、人的ミスの余地を減らしながら、スケーラブルなアプリケーションエコシステムを支援します。
• 手動セットアップの複雑さを解消し、Okta の顧客管理者が Auth0 対応 OIN 統合のインスタンスをすばやく追加できるようにします。

​

仕組み

Express Configuration API を使用すると、顧客向けに OIN で公開された Auth0 アプリケーションで、Okta 接続 に対する Express Configuration を利用できます。Express Configuration は、Auth0 の 組織 内で OpenID Connect、SCIM、Universal Logout をサポートします。

OIN 内の Auth0 アプリの Express Configuration ワークフローを確認します。

• Okta 管理者は Okta ポータルにサインインし、OIN から Express Configuration が有効なアプリケーションを選択します。
• Okta 管理者は Sign On セクションに移動し、Express Configure SSO & UL を選択します。すると、Auth0 Universal Login の画面にリダイレクトされます。

• Okta 管理者は、Express Configuration の実行を許可されたアプリケーション ユーザーの認証情報を入力します。Auth0 では、これは 組織 のメンバーであり、組織ロール またはその他の認可方法によって Express Configuration を実行する権限が付与されているユーザーを指します。

• 認証後、Auth0 は Okta 管理者に同意を求めます。

• 同意すると、Okta は Express Configuration API を使用して、Okta 管理者が所属する Auth0 の組織内に Okta 接続 を自動的に構成します。

• その後、Okta 管理者はアプリケーション インスタンスにユーザーを割り当てることができ、シングルサインオンがすぐに機能することを確認できます。

Auth0 開発者は、SCIM と Universal Logout の Express Configuration を許可するように OIN 統合を構成することもできます。どちらも推奨されます。

• SCIM が有効になっている場合、Okta 管理者はアプリケーションの詳細の Provisioning セクションに移動し、Express Configure SCIM を選択して SCIM を構成できます。
• Universal Logout が有効になっている場合は、OpenID Connect 統合の一部として自動的に構成されます。

​

前提条件

Express Configuration を有効にしてアプリケーションを OIN に公開するには、次の要件を満たしている必要があります。

• Okta Integrator Free Plan org を所有し、Super Admin ロールまたは App and Org Admin ロールのいずれかにアクセスできること
• 必要な数の顧客に対して Okta 接続タイプと組織機能を利用できる Auth0 サブスクリプション があること
• Multi-Organization Architecture を使用して Auth0 と統合された SaaS アプリケーションがあること
  • これには、Auth0 でアプリケーションを Regular Web Application または Single-Page Application として登録し、各顧客がそれぞれ固有の IDプロバイダー を使用してそのアプリケーションにサインインできるようにすることが含まれます。
• Express Configuration を使用する各顧客に対して、Auth0 組織 がデプロイ済みであるか、デプロイ可能であること。組織と組織ロールは、特定のユーザーが所属する組織内でのみ Express Configuration を実行し、Okta 接続を作成できるように認可するために使用されます。
• Auth0 テナントで Enable Application Connections テナント設定が無効になっていること

ヒント: Auth0 Organizations と組織ロールを含むマルチテナント アーキテクチャを実装したサンプルアプリケーションを確認するには、SaaStart reference application を参照してください。

​

Express Configuration 用にアプリケーションを設定する

Auth0 Dashboard では、Auth0 開発者がアプリケーションで Express Configuration を有効にし、OIN に公開するまでの手順を案内します。

エンドツーエンドの設定と公開のプロセスを完了するには、本番 Auth0 テナントの Auth0 Admin ロールが必要です。

テナントで Express Configuration を設定するには、次の Auth0 コンポーネントを構成します。

• Initiate Login URI Template が設定された登録済みアプリケーション
• 接続プロファイル (CP)
• ユーザー属性プロファイル
• 組織のログイン設定
• 管理者のログインと同意の設定

​

Initiate Login URI Template を使用してアプリケーションを登録する

1. Auth0 Dashboard で、アプリケーションを Regular Web Application または Single-Page Application として登録します。
2. 登録後、作成したアプリケーションを選択し、Okta Integration Network タブに移動して Express Configuration セットアップウィザードを開始します。
3. Get Started を選択します。
4. 前提条件を確認し、続行 を選択します。
5. Initiate Login URI Template を登録します。このテンプレートでは、認証のためにエンドユーザーを Auth0 の /authorize エンドポイントに自動的にリダイレクトするエンドポイントをアプリケーションに実装します。ログインエンドポイントの例を確認するには、Express SDK Quickstart の /login ルートを参照してください。
   • アプリケーションインスタンスに対して Express Configuration が開始されると、Okta は Initiate Login URI Template を使用して エンドユーザー ダッシュボード からアプリケーションを起動します。
   • (任意) 使用する組織または接続を識別するために、Auth0 の /authorize エンドポイントに organization_name、organization_id,、connection_name を設定します。エンドユーザー ダッシュボードから URL が起動されると、Okta はこれらの変数を動的に置き換えます。例: https://{organization_name}.your-app.com?connection={connection_name}。

Initiate Login URI の例:

https://your-app.com/login
https://your-app.com/login?connection={connection_name}
https://{organization_name}.your-app.com?connection={connection_name}

​

接続プロファイル

Initiate Login URI Template では、接続プロファイルを追加することもできます。接続プロファイル を使用すると、Express Configuration で作成する際に、接続の非公開設定をどのように構成するかを Auth0 で指定できます。これには、接続が Auth0 の Universal Login 機能や組織機能とどのように連携するかを制御する設定も含まれます。

• Auth0 で接続名をどのように作成するかに関するオプション
  • 接続で SCIM や Universal Logout を使用するためのオプション (推奨)
  • 接続のエンドユーザーが、同意した管理者の組織のメンバーに自動的に追加されることを許可するオプション
  • Auth0 の Universal Login ページで、その接続の Show as button 設定をどうするかに関するオプション

接続プロファイルが構成されていない場合、Auth0 は、Express Configuration で構成された接続向けに、一般的で推奨される設定を適用したデフォルトの接続プロファイルを提供します。

デフォルトの CP をカスタマイズする方法については、接続プロファイル を参照してください。

​

ユーザー属性プロファイル

Initiate Login URI Template では、ユーザー属性プロファイル を追加できます。ユーザー属性プロファイル (UAP) を使用すると、Auth0 を利用する開発者は、Auth0 がサポートするさまざまなプロトコル間でユーザー属性を一貫して定義、管理、マッピングできます。Express Configuration と併用すると、ユーザー属性プロファイルにより、Express Configuration で生成された Okta 接続に書き込まれる OpenID Connect および SCIM の属性マップをカスタマイズできます。

ユーザー属性プロファイルが設定されていない場合、Auth0 は、Okta 接続タイプで使用される OpenID Connect や SCIM を含むすべてのプロトコル向けに、一般的で推奨されるマッピングを含むデフォルトのユーザー属性プロファイルを提供します。

デフォルトの UAP をカスタマイズする方法については、ユーザー属性プロファイル を参照してください。

​

組織のログイン設定

特定の組織のユーザーが分離された接続を作成できるようにするには Auth0 組織 が必要ですが、ビジネスユーザー向けの組織ベースのログインフロー をサポートするために、アプリケーションの既存のログインフローを変更する必要はありません。

• アプリケーションで現在 Identifier-First login experience とホームレルムディスカバリーを使用している場合は、ホームレルムディスカバリーを有効にする方法について Enabling Home Realm Discovery セクションを参照してください。
• enabled_clients で複数のアプリケーションを有効にし、Express Configuration の接続で使用する場合は、Enabling Multiple Auth0 Applications Under a Single Integration を参照してください。

現在のアプリケーション構成で組織ベースのログインフローを使用していない場合は、Enable this application for created connections 設定を選択できます。有効にすると、Okta 接続の各 Express Configuration がアプリケーションに直接関連付けられます。接続では必須の enabled_clients 設定を使用してください。

​

管理者ログインと同意の設定

Express Configuration を有効にすると、Auth0 は追加のクライアントアプリケーション ID を作成します。これは、Okta と Auth0 間の管理者による同意フローで OIN が使用するものです。Okta は、OIN に公開される個々のアプリケーション統合ごとに 1 つの OIN クライアントを作成します。

OIN に公開するアプリケーションの Configure Integration Profile で、管理者ログインと同意の設定を行います。

1. Auth0 Dashboard > Applications に移動します。
2. OIN に公開するアプリケーションを選択します。
3. Okta Integration Network を選択します。
4. 必要な前提条件を満たしていることを確認し、続行 を選択します。
5. Configure Integration Profile セクションで、Admin Settings のオプションを設定します。

• Admin Login Domain: Web ブラウザーでの同意フローの一環として、Okta がリダイレクト先として使用する Auth0 テナントのドメインです。Auth0 でカスタムドメイン名を設定している場合は、それを使用してください。詳細については、Custom Domains を参照してください。

  • Display Name of the OIN Express Configuration Application: 同意ダイアログに表示される OIN クライアントアプリケーションの名前です。

  • Admin Login Flow: OIN クライアントアプリケーションの Organization login フローを定義する設定で、Okta 管理者が Okta コンソールから Express Configuration を実行するときに使用されます。次のオプションから選択します。

    • Prompt for Organization: まず管理者に組織の選択を求め、選択した Auth0 組織のログイン画面を表示します。管理者は、その組織で設定されている 既存の接続 を使用してサインインできます。

    • Prompt for Credentials: まず管理者にログイン資格情報の入力を求めます。このオプションを選択すると、管理者ユーザーを含む接続を選択できるボタンが表示されます。これには、共有データベース接続、パスワードレスのメール接続、またはすべての Auth0 組織に関連付け可能なその他の接続を使用できます。

  • Admin Role: Express Configuration を実行するには、管理者に適切な権限が割り当てられている必要があります。現在の Auth0 デプロイメントに最も適した方法で管理者を認可する手順については、Assign express configuration permissions to users を参照してください。

最適な同意エクスペリエンスのために、Customize Consent Prompts で説明されているとおり、テナントの use_scope_descriptions_for_consent フラグを true に設定してください。後で統合をテストして検証する際に、同意プロンプトを確認する機会があります。

​

ユーザーに権限を割り当てる

Okta では、Auth0 を利用した SaaS アプリケーションで Express Configuration を実行するために、管理者は必要な権限を持つアプリケーションユーザーアカウントを保有している必要があります。

Auth0 では、Express Configuration 用に設定された接続が作成されている Auth0 組織 のメンバーであれば、どのアプリケーションユーザーにもこの権限を付与できます。これには、以下のユーザーが含まれます。

• 単一の組織専用に作成された専用データベース接続内のユーザー
• 1 つ以上の組織のメンバーである共有データベース接続内のユーザー
• 1 つ以上の組織のメンバーであるパスワードレスのメール接続を使用するユーザー
• 1 つ以上の組織のメンバーであるソーシャル接続または既存のエンタープライズ接続内のユーザー

これらの条件が満たされると、Auth0 では Express Configuration の権限を割り当てるための柔軟な方法が提供され、開発者は現在の Auth0 デプロイメントに最適な方法を選択できます。

方法	推奨対象
既存のユーザーロールに Express Configuration の権限を割り当てる	Auth0 テナント内に既存のアプリケーションユーザー ロール がある顧客。
SaaStart reference application に示されているように、Express Configuration の権限が必要なアプリケーションユーザーに新しいロールを割り当てる。	Auth0 の ロール 機能を使用して、個々のユーザーに Express Configuration の権限を付与したい顧客。これは Auth0 Dashboard または Management API で実行できます。
Post-Login Action を使用して、属性ベースのアクセス制御により権限を動的に割り当てる	現在 Auth0 の ロール 機能を使用しておらず、ロールを割り当てるために Auth0 Dashboard や Management API を使用する代わりに、Post-Login Action を使ってユーザー属性に基づいて権限を動的に割り当てたい顧客。

Express Configuration を使用する管理者アカウントのプロビジョニングに関するヒントについては、Customer Enablement を参照してください。

​

既存のアプリケーションユーザー用ロールに権限を割り当てる

アプリケーションロールと API 権限に Auth0 の RBAC 機能 を使用していて、アプリケーションをデプロイする IT 管理者に割り当てる管理ユーザー向けのロールがすでに 1 つ以上ある場合は、Express Configuration 権限の割り当てにこの方法を使用します。

必要な API 権限:

権限名	API (リソースサーバー) 識別子
express_configure:sso	urn:auth0:express-configure
express_configure:scim	urn:auth0:express-configure

Auth0 Dashboard と Management API でのロールの割り当てについて詳しくは、ロールに権限を追加する を参照してください。

​

アプリケーションユーザーに新しいロールを割り当てる

アプリケーションのロールと API 権限に Auth0 の RBAC 機能 を使用している一方で、アプリケーションのデプロイを担当する IT 管理者のような管理ユーザーに対応するロールがない場合は、Express Configuration 権限の割り当てにこの方法を使用します。

この方法は、現在は Auth0 の RBAC 機能 を使用していないものの、Auth0 Dashboard または Management API を使ってアクセスを許可するユーザーをきめ細かく制御するために活用したい Auth0 開発者にも適しています。

​

ロールを作成する

Auth0 Dashboard、Management API、または Auth0 CLI を使用して、ロールを作成できます。この例では Auth0 CLI を使用します。

auth0 roles create \
  --name "EXPRESS_CONFIGURE_ADMIN_ROLE" \
  --description "Administrator role for Express Configuration"

​

ロールに権限を割り当てる

指定したロールに express_configuration:sso 権限と express_configuration:scim 権限を割り当てます。権限を付与するロールの ID に合わせて、$ROLE_ID を置き換えてください。

この方法を使用する場合は、Express Configuration 権限が必要な新規の組織ユーザーにこのロールを割り当てるよう、顧客のオンボーディング プロセスを更新する必要があります。

auth0 roles permissions add "$ROLE_ID" \
  --api-id "urn:auth0:express-configure" \
  --permissions "express_configure:sso"

auth0 roles permissions add "$ROLE_ID" \
  --api-id "urn:auth0:express-configure" \
  --permissions "express_configure:scim"

既存の組織ユーザーへのロールの割り当てについて詳しくは、メンバーのロールを追加を参照してください。

​

post-login Action を使用して、ユーザー属性に基づいて権限を割り当てる

ロールベースのアクセス制御 (RBAC) 、Management API、または Auth0 Dashboard でユーザーロールを割り当てる代わりに、Auth0 の post-login Action を使用してユーザー属性に基づいて権限を動的に割り当てる場合は、Express Configuration の権限割り当てにこの方法を使用します。

これは、Auth0 metadata のカスタム権限を使用する属性ベースの認可モデルで Auth0 を導入しているお客様に適しています。

例
次の例では、post-login Action を使用して、既存のカスタムユーザー属性 user.app_metadata.is_admin の値に基づいて権限を割り当てます。

/**
* ロールの割り当てではなく、カスタムロジックに基づいてExpress Configurationの権限を割り当てます
*/
exports.onExecutePostLogin = async (event, api) => {


 //リクエストがEC APIのアクセストークン用かどうかを確認する
 if (event.resource_server && event.resource_server.identifier === "urn:auth0:express-configure") {


   //カスタム条件に基づいて権限を追加する
   if (event.user.app_metadata && event.user.app_metadata.is_admin === true) {
     api.accessToken.addScope("express_configure:sso");
     api.accessToken.addScope("express_configure:scim");
   }
   //ECのアクセストークンがリクエストされた場合はアクセスを拒否する
   else {
     api.access.deny('Access denied');
   }
 }
};

​

ホームレルム検出を有効にする

Express Configuration を実行する前に、HRD を有効にするため、顧客のオンボーディングプロセスの一環として顧客のメールアドレスを収集し、検証しておく必要があります。

アプリケーションで Identifier-First login experience を使用し、メールアドレスに基づくホームレルムディスカバリー (HRD) によってユーザーを対応する IDプロバイダー (IdP) に関連付ける場合は、Auth0 Actions と組み合わせて Express Configuration を使用できます。

メールアドレスは、Express Configuration ワークフローの実行中に post-login Actions からアクセスできる場所に保存する必要があります。保存先の例を以下に示します。

• 1 つ以上のメールドメインを、顧客の Auth0 組織の organization metadata に保存できます。
• post-login Action から API 呼び出しを行い、検証済みドメインを保存している環境内の任意のシステムから取得することもできます。

管理ユーザーが Okta ポータルで Express Configuration を開始して認証すると、これらの Action によって Okta が受け取るトークンにメールドメインが追加されます。Okta はそれを抽出し、正しい HRD 設定で Okta 接続をセットアップするために使用します。

例 1
この例では、検証済みドメインは Auth0 組織内の接続メタデータに保存されます。この方法では、1 つ以上のメールドメインをカンマ区切りの文字列として、organization metadata の domains というキーの下に保存する必要があります。

値の例: test.com,test2.com

exports.onExecutePostLogin = async (event, api) => {
if (event?.resource_server?.identifier === "urn:auth0:express-configure") {
  if (event.organization && event.organization.metadata && event.organization.metadata.domains)
  {
    var domain_aliases = event.organization.metadata.domains.replace(/ /g,'').split(',');
    var express_configuration = {
      "domain_aliases": domain_aliases
     };
     api.accessToken.setCustomClaim("express_configuration", express_configuration);
  }
}
};

例 2
この例では、post-login Action が API を呼び出して、お使いの環境内のストレージシステムから検証済みのドメインを取得します。

/**
*/
exports.onExecutePostLogin = async (event, api) => {
 if (event?.resource_server?.identifier === "urn:auth0:express-configure") {
    const axios = require("axios");
    // カスタムAPIコールをここで設定してください 
    const domains = await axios.get("https://example.org/endpoint");
     var express_configuration = {
     "domain_aliases": domains
      };
      api.accessToken.setCustomClaim("express_configuration", express_configuration);
  
 }
};

​

接続をまたいで管理者アカウントの照合を維持する

Auth0 では、異なる接続に対して同じメールアドレスを持つユーザーアカウントをプロビジョニングできます。エンドユーザーは、勤務先のメールアドレスでデータベース接続、ソーシャル、またはパスワードレスのアカウントを持ちながら、フェデレーションされた Okta アカウントでも同じメールアドレスを使用している場合があります。

Admin login and consent flow の Prompt for Credentials オプションを使用すると、組織 に追加された後は、ホーム レルム ディスカバリーによって、特定のドメイン接尾辞に一致するユーザーが他の種類の接続ではなく新しい Okta 接続に照合されるようになります。この 組織 のログイン動作の詳細については、Identifier First Authentication with prompt for credentials を参照してください。

この動作が有効になるのは、初回の Auth0 管理者ユーザー セッションの有効期限が切れた後に、顧客が Express Configuration を再度実行した場合のみです。管理者アカウントの識別子が新しい Okta 接続に一致するメールアドレスである場合、管理者はその接続にリダイレクトされます。

この動作は、次のいずれかの方法で管理または回避できます。

• Admin login and consent flow の Prompt for Organization オプションを使用します。
  • 一致する検証済みメールアドレスを含む新しい Okta アカウントがプロビジョニングされた後、そのアカウントに対して Express Configuration の権限を有効にします。
  • Auth0 組織 を Express Configuration の管理者同意フローでのみ使用し、アプリケーションの利用体験では使用していない場合は、Configure SaaS Application Properties で説明されている enable_organization プロパティを無効にすることで、この問題を解決できます。
  • 管理者ユーザーの識別子が、データベース接続の username など、メールアドレスではない場合は問題になりません。

​

1 つの統合で複数のアプリケーションを有効にする

Okta 接続の 1 つの Express Configuration のエンドユーザーが、テナント内の複数のアプリケーションにアクセスできるようにするには、登録済みの Web アプリケーションに linked_clients プロパティを設定します。

この設定を変更するには、Auth0 Management API を使用して登録済みの Web アプリケーションを取得します。{yourAppId} は登録済みアプリケーションのクライアントIDに、{yourAccessToken} は Management API v2 のアクセストークンに置き換えてください。Management API で使用するアクセストークンを取得する方法については、Management API Access Tokensを参照してください。

curl --request GET \
  --url 'https://{yourDomain}/api/v2/clients/{yourAppId}' \
  --header 'authorization: Bearer {yourAccessToken}'

レスポンスから express_configuration プロパティを取り出し、追加するアプリケーション ID の配列を linked_clients プロパティに追加して、登録済みの Web アプリケーションを更新します:

curl --request PATCH \
  --url 'https://{yourDomain}/api/v2/clients/{yourAppId}' \
  --data '{"express_configuration": 
  {"admin_login_domain":"TENANT.auth0.com",
    "connection_profile_id":"cop_xxxxxxxxxxxxxxx",
    "enable_client":true,
    "enable_organization":true,
    "initiate_login_uri_template":"https://example.org",
    "okta_oin_client_id":"LDiGbUeiAYjRB5a4yOGfBvxxxxxxxxxxx",
    "user_attribute_profile_id":"uap_1ctMVQUg8jxxxxxxxxxxxx",   

     "linked_clients": [ 
        { "client_id": "KJM86F2susguvsasSeAsIxxxxxxxxxxx" }, 
	  { "client_id": "FIXwZCf5iUElvqy6eidlfxxxxxxxxxxx" }
      ] 
     }
  }' \
  --header 'cache-control: no-cache' \
  --header 'content-type: application/json' \
  --header 'authorization: Bearer {yourAccessToken}'

Express Configuration を実行すると、linked_clients プロパティ内のすべてのアプリケーション ID が、Okta 接続の enabled_clients プロパティに追加されます。

​

統合を OIN に公開する

基本構成を作成したら、OIN への申請プロセスを開始できます。このプロセスの一環として、公開前に Express Configuration をエンドツーエンドで十分にテストできます。

1. OIN にアプリケーションを登録する 2. OIN 統合に Express Configuration を追加する 3. OIN の公開鍵を設定する 4. Express Configuration 統合をテストして検証する 5. OIN への申請を完了する

​

OIN でアプリケーションを登録する

OIN の要件

OIN 内の新規または既存のアプリケーションに Express Configuration を追加するには、次のものが必要です。

• テストに使用する Auth0 対応 Web アプリケーションのインスタンス
• Okta Integrator Free Plan org (Super Admin ロール、または App Admin ロールと Org Admin ロールの両方にアクセスできること) 。
  • 基本的なテストを完了するには、Okta Integrator Free Plan org を Auth0 テナント内の Okta 接続 として構成し、Auth0 対応 Web アプリケーションで使用できるように有効化しておく必要があります
• Okta Browser Plugin をインストールした Google Chrome ブラウザー (OIN Wizard の要件を参照)

1. サインアップ時に使用したユーザーアカウント、または SUPER_ADMIN ロール、もしくは Okta の APP_ADMIN 管理者ロールと ORG_ADMIN 管理者ロールの両方が割り当てられたアカウントで、Okta Integrator Free Plan org にサインインします。
2. Admin Console で Applications > Your OIN Integrations に移動します。
3. 新しいアプリケーションの場合は、Build new OIN integration を選択します。それ以外の場合は、既存の OIN Integration を選択します。OIN Wizard が表示されます。

4. Add integration capabilities で、SSO プロトコルとして OpenID Connect (OIDC) を選択します。
5. 必要に応じて Universal Logout と SCIM 2.0 を選択できます。これらはいずれもすべての Okta 統合に強く推奨されており、Express Configuration でサポートされています。
6. Add integration details を選択します。
7. 必要に応じて OIN Catalog Properties セクションに入力します。詳細については、OIN Catalog Properties を参照してください。
8. Configure your integration を選択します。この画面でアプリケーションの Express Configuration を有効にします。

​

OIN 統合に Express Configuration を追加する

登録済みの OIN 統合で Express Configuration 機能を有効にするには、次の手順に従います。

1. OIN Wizard の Configure your integration 画面で、Enable Express Configuration を選択します。Auth0 テナントから取得する情報の入力を求めるウィンドウが表示されます。

2. 新しいブラウザーウィンドウで、Auth0 Dashboard > Applications > [Application] > Okta Integration Network > Create OIN Integration に移動し、画面に表示されている情報をコピーします。

3. OIN Wizard の Configure your integration 画面に戻り、その情報を Express Configuration Information フィールドに貼り付けます。

4. 続行 を選択します。

​

OIN 公開鍵を設定する

次に、Auth0 にアップロードするために必要な公開鍵ファイルを Okta からダウンロードする画面の指示に従います。

1. OIN Wizard の Express Configuration for Auth0 apps ウィンドウで、Download Key (.pem) を選択し、鍵をローカルデバイスに保存します。

2. ファイルを Auth0 Dashboard > Applications > [Application] > Okta Integration Network > Create OIN Integration にアップロードします。

3. Save を選択します。

4. Okta ポータルの Configure your integration 画面に戻り、Finish を選択します。これにより、統合に必要な設定フィールドの多くが自動入力されます。

​

​統合の設定を完了する

1. OIDC Properties で、次のフィールドを設定します。

   • Redirect URIs は、Auth0 テナントのコールバック URI に自動的に設定されます。テナントのカスタムドメインまたは auth0.com ドメインを使用できます。例: https://tenant.auth0.com/login/callback
   • Initiate Login URI は、Initiate Login URI Template を使用してアプリケーションを登録する で説明されているように、Auth0 でアプリケーション用に設定した値に自動的に設定されます。Okta はこの URL を使用して、エンドユーザーダッシュボードからアプリケーションを起動します。この画面に表示される統合変数に対応するよう、変数名が変更されている点に注意してください。
   • (任意) Post-Logout URL を、アプリのサインアウト後のリダイレクト URI に設定します。これは、エンドユーザーがアプリからサインアウトした後にリダイレクトする先です。サインアウト URI がテナントごとに異なる場合は、統合変数を使用できます。
   • Configuration guide URL に、Express Configuration を使用して Okta とアプリ間の SSO を設定する方法を説明した顧客向け手順へのリンクを設定します。詳細は、Customer configuration document guidelines を参照してください。
   

2. Universal Logout が選択されている場合は、Universal logout properties で次の値が設定されていることを確認します。

   • Global token revocation エンドポイントは自動的に設定されます。この値は、Express Configuration の実行時に動的に置き換えられます。
   • Subject format は自動的に Issuer and Subject identifier に設定されます。
   • Auth0 とアプリケーション間で OIDC back-channel ログアウトを使用しておらず、アプリケーションで リフレッシュトークン を使用している場合は、Partial support をチェックします。
   

3. SCIM 2.0 が選択されている場合は、SCIM provisioning properties で次の値が設定されていることを確認します。

   • Base URL は統合変数に設定する必要があります。この値は、Express Configuration の実行時に動的に置き換えられます。
   • User Operations は、自動的に Create、Read、Update、Deactivate に設定されます。
   • Express Configuration を使用して Okta とアプリ間の SSO を設定する方法を説明した顧客向け手順へのリンクを設定します。詳細は、Customer configuration document guidelines を参照してください。
     

4. Get started with testing を選択します。

​

統合をテストして検証する

公開鍵を Auth0 にアップロードしたら、Okta Free Integrator 組織を使用して Express Configuration をテストできます。

1. Okta OIN Operations チームと共有できる Auth0 の組織と username/password アカウントを作成します。
   • この目的で Auth0 の組織と username/password アカウントを作成するには、顧客有効化フローの例の手順に従ってください。
   • 必要に応じて、新しいアプリケーション テナントを作成するなど、テスト用の組織がログインできるようにするために、アプリケーション側で追加の対応を行ってください。
2. テストアカウントを作成したら、スーパー管理者 (SUPER_ADMIN) ロール、またはアプリ (APP_ADMIN) 管理者ロールと組織 (ORG_ADMIN) 管理者ロールを持つユーザーとして、Okta Integrator Free 組織にサインインします。詳しくはロールを参照してください。
3. Okta 管理コンソールで Applications > Your OIN Integrations に移動します。OIN 統合の名前を選択します。
4. Configure your integration を選択します。次に Get started with testing. を選択します。
5. Account URL には、アプリケーションのログインページを設定します。Okta OIN Operations のエンジニアがこの URL にアクセスし、後続のフィールドで指定したアカウント認証情報を使用してアプリにサインインします。
6. Username と Password には、Express Configuration のテスト用に設定したテスト組織管理者アカウントのユーザー名とパスワードを設定します。
7. Support Contact には、統合について Okta が貴社に連絡するためのメールアドレスを設定します。このメールアドレスが OIN カタログや顧客に公開されることはありません。内部の Okta チームにのみ表示されます。
8. OIDC Tests で、Just-In Time Provisioning には No を選択してこのテストをスキップし、SP Initiate URL にはアプリケーション インスタンスのログイン開始 URL を設定します。
   
9. Test your integration を選択します。
10. Generate Instance、次に Done を選択します。
11. Sign On タブに移動します。
12. シングルサインオンと Universal Logout の Express Configuration をテストするには、Express Configure SSO & UL を選択します。
    
13. Auth0 の Universal Login ページにリダイレクトされたら、組織管理者アカウントでサインインし、データ共有に同意します。
14. SCIM をテストするには、Provisioning、次に Express Configure SCIM を選択します。Auth0 の Universal Login にリダイレクトされたら、同意プロンプトを進めてください。完了すると、SCIM 統合が設定されます。
15. 次に、Assignments タブを選択し、認証情報を把握している Okta Free Integrator 組織のユーザーを割り当てます。適切なユーザーが存在しない場合は、ユーザーを手動で追加する手順に従ってください。SCIM が有効になっている場合、そのユーザーは Auth0 テナントにプロビジョニングされるはずです。Auth0 Dashboard で確認してください。
16. SSO をテストするには、割り当てたユーザーアカウントとテスト インスタンスを使用します。ユーザーアカウントの認証情報でログインします。
17. Universal Logout をテストするには、Universal Logout をテストするの手順に従ってください。

​

申請を完了する

前のセクションで基本的なテストは完了しています。申請を完了するには、設定がいくつかの自動テストに合格する必要があります。

1. アプリケーションインスタンスで Begin Testing を選択し、申請の完了に進みます。
2. Express Configuration でテストしたインスタンス名の横にある Add to Tester を選択します。
3. 自動 SSO テストを完了するには、IDP flow テストおよび/または SP flow テストの Run test を選択します。これらのテストには Okta Browser Plugin が必要です。詳細は、OIN Wizard Requirements を参照してください。
   • アプリケーションインスタンスに割り当てた Okta Free Integration Organization ユーザーでサインインします。プラグインがアプリケーションへのサインイン成功を検出すると、その時点でテストは合格します。これらのテストの詳細については、Test your integration を参照してください。
   • ログインテスト中にエラーメッセージ invalid_request (no connections enabled for the client) が表示された場合は、数分待ってから再試行してください。新しく作成した接続は、HRD などの機能で利用できるようになるまで数分かかることがあります。
4. SCIM に必要な Runscope テストを完了するには、Okta SCIM 2.0 Spec Tests を使用し、Test your SCIM API の手順に従ってください。
   • 2 つ目の SCIM トークンには、Authentication > Enterprise > Okta > [your-express-configred-connection] > Provisioning > Sync user profiles using SCIM > Setup セクションを使用します。
   • 完了したら、OIN Wizard の Link to Runscope spec test results フィールドと Link to Runscope CRUD test results フィールドに、共有可能な Runscope テスト URL を入力します。
5. 完了したら、Submit Integration を選択します。

​

顧客向けの有効化

アプリケーションを OIN に公開したら、Okta の Express Configuration をサポートしていることが分かるように、製品ドキュメントを更新できます。製品ドキュメントには、どのユーザーロールまたはユーザータイプに Express Configuration を実行する権限があるかを明記してください。

アプリケーションですでに Auth0 組織 を利用しており、SaaStart リファレンスアプリケーションで示されているように組織管理者ロールを使用している場合は、そのロールに Express Configuration の権限を追加できます。

まだ顧客向けに Auth0 組織 を導入していない場合、またはアプリケーションで管理ユーザーを実装していない場合は、顧客オンボーディングフローの例を参照してください。

​

顧客の有効化フローの例

顧客のオンボーディング プロセスでは、次の情報を収集する必要があります。

• 顧客の組織名
• Express Configuration を実行する権限を持つ顧客管理者のメールアドレス
• 管理者のドメインを含む、顧客の IdP がユーザーに対して発行する検証済みメールドメイン

この情報は、手動で収集しても、顧客向けのサインアップまたはオンボーディング エクスペリエンスを使用して収集してもかまいません。収集した情報を使用して、この顧客向けの Auth0 組織と管理者ユーザー アカウントを作成します。

1. Auth0 組織を作成します
2. データベース接続やメールのパスワードレスなどの Auth0 接続に、管理者ユーザー アカウントを作成します。
3. その接続を Auth0 組織に関連付けます。Membership On Authentication を無効にします。
4. 管理者ユーザー アカウントを Auth0 組織のメンバーとして追加します。
5. Express Configuration を実行する権限を持つ組織ロールを管理者ユーザーに割り当てます。

​

Auth0 CLI の例

Auth0 CLI を初期化して認証する Auth0 CLI を使用して Auth0 に認証します。

auth0 login --scopes "create:users,create:organizations,create:organization_members,create:organization_member_roles,create:organization_connections"

Auth0 組織を作成する 組織の名前と、スペースを含まない短い名前を入力します。複数のメールアドレスのドメインを収集した場合は、それらを組織のメタデータとして追加します。

auth0 orgs create --json \
--display "organization_display_name" \
--name "organization_short_name" \
--metadata 'domains=["domain1.com", "domain2.com"]'

返された org_id を控えておきます。

組織の管理者アカウントを作成する この例では、メールのパスワードレス接続にユーザーを作成します。これには、email 接続タイプが必要です。このコマンドでは、Express Configuration の実行を許可するユーザーのメールアドレスを入力する必要があります。

auth0 api users \
--data '{"email":"[e-mail]","connection":"email", "email_verified":true}'

ヒント

Okta OIN 運用チームにユーザー名とパスワードのテストアカウントを提供するためにこの組織を作成している場合は、共有データベース接続または専用データベース接続のいずれかにテストアカウントを作成してください。

auth0 api users \
--data '{"email":"[e-mail]","connection":"db_connection_name_here", "password": "add_a_long_password_here"}'

返された user_id を控えておきます。

接続を組織に関連付ける

接続 ID を取得します。

auth0 api get "connections" -q "name=connection_name_here"

接続 ID を組織 ID (org_id) に紐付けます。

auth0 api post "organizations/org_id_here/enabled_connections" \
--data '{ "connection_id": "connection_id_here" };

管理者ユーザーを組織のメンバーに追加する org_id と user_id が必要です。

auth0 api post "organizations/org_id_here/members" \
--data '{ "members": ["user_id__here"] }'

Express Configuration 権限を持つ組織ロールを割り当てる ユーザーに Express Configuration 権限を割り当てる で設定した Express Configuration 権限付きロールの ID を取得します。

auth0 api get "roles" -q "name_filter=role_name_here"

user_id と org_id にロールIDを割り当てます。

auth0 api post "organizations/org_id_here/members/user_id_here/roles" --data '{ "roles": ["role_id_here"] }'

完了すると、顧客は組織の管理者アカウントを使用して、お客様の OIN 統合 で顧客の Okta 組織の Express Configuration を実行できます。

​

管理者アカウントをプロビジョニングする際の推奨事項

既存のユーザーアカウントを使用する場合も、Express Configuration を有効にするために新しいアカウントをプロビジョニングする場合も、以下の推奨事項に従ってください。

​

勤務先のメールアドレスを使用する

非フェデレーションの管理者アカウントがデータベース、パスワードレスのメール、またはソーシャルユーザーアカウントのいずれであっても、email 属性の値は、Okta Enterprise のユーザーアカウントにプロビジョニングされるユーザーの勤務先メールアドレス (例: [e-mail]) と一致させることをお勧めします。

Auth0 では、これらのメールアドレスを メールアドレスの確認フロー を使用して確認することも推奨しています。

​

多要素認証を使用する

ログインのたびに多要素認証を必須にすることで、Express Configuration フローのセキュリティをさらに強化できます。

この Post-Login Action の例では、Express Configuration が実行されるたびに、デバイスの生体認証を使用する WebAuthn や メールで送信されるワンタイムパスワード などの認証要素を、条件に応じて要求する方法を示しています。

この例の Action を使用するには、Auth0 テナントで これらの認証要素を有効にし、Customize MFA Factors using Actions オプションを選択する必要があります。

exports.onExecutePostLogin = async (event, api) => {


if (event.resource_server && event.resource_server.identifier === "urn:auth0:express-configure") {


   api.multifactor.enable('any');
  api.authentication.challengeWith({ type: 'email' });


  if (!event.user.enrolledFactors.some(m => m.type === 'webauthn-platform')) {
     api.authentication.enrollWith({type: 'webauthn-platform'});
   } else {
     api.authentication.challengeWith({type: 'webauthn-platform'});
  }
 }
}

​

Express Configuration の使用状況を監視する

Express Configuration の使用状況は、設定済みの各アプリケーションの OIN クライアントID で絞り込むことで、Auth0 テナントログ から確認できます。これには、すべての管理者ユーザーのログインアクティビティに加え、Okta Enterprise 接続の作成と管理に関するすべての API 操作が含まれます。

アプリケーションの OIN クライアントID は、次の場所で確認できます。

• Auth0 Dashboard の Applications > [Application] > Okta Integration Network > Create OIN Integration セクション

  • Management API でアプリケーションを表示したときの express_configuration.okta_oin_client_id プロパティ

クライアントID を使用したログ検索の詳細については、Log Search Query Syntax を参照してください。

​

制限事項

• 1 つの OIN 統合で使用できる Auth0 テナントは 1 つだけです。同じアプリケーションを複数の Auth0 リージョンにデプロイする場合は、各リージョンごとに専用の OIN 統合が必要です
• 1 つの Okta 組織内の 1 つの OIN 統合で、対応する 1 つの Auth0 組織内に一意の Okta 接続を 1 つ作成できます。Okta 組織内で OIN アプリケーションの複数のインスタンスに対して Express configuration はサポートされていません
• OIN に掲載される一意の統合ごとに、独立した Okta 接続が作成されます。ホーム レルム検出を伴う Identifier-First ログイン エクスペリエンス を必要とするアプリケーションが複数ある場合は、1 つの統合の下で複数のアプリケーションを公開する ことをお勧めします。
• 1 つの統合の下で複数のアプリケーションを有効にする 場合、Okta の エンドユーザー ダッシュボード に表示されるのはメインの OIN アプリケーションのみです。

​

Management API リファレンス

特定のアプリケーションで Auth0 Dashboard の代わりに Management API を使用して Express Configuration を有効にするには、以下の例を参照してください。

​

Okta OIN Express Configuration System API を作成する

組織管理者の認証に使用するリソースサーバーを登録します。これは、テナント内のアプリ向けに Express Configuration を設定するためにダッシュボードが一度も使用されていない場合にのみ必要です。

例:

POST /api/v2/resource-servers
{
    "name": "Okta OIN Express Configuration API",
    "identifier": "urn:auth0:express-configure"
  }

エンドポイント リファレンス

​

ユーザー属性プロファイルを作成

ユーザー属性プロファイル を作成します。この手順が必要なのは、既存のプロファイルがない場合、または開発者がカスタムプロファイルを使用する場合のみです。

ユーザー属性プロファイルの既定セットを基に開始するには、まず GET /api/v2/user-attribute-profiles/templates エンドポイントを呼び出し、そのレスポンスをリクエスト本文に使用してユーザー属性プロファイルを作成します。

例:

GET /api/v2/user-attribute-profiles/templates

エンドポイントのリファレンス

POST /api/v2/user-attribute-profiles
{
    "name": "Okta OIN Express Configuration API",
    "identifier": "urn:auth0:express-configure"
}

エンドポイントリファレンス

​

接続プロファイルを作成

接続プロファイルを作成します。この手順は、既存のプロファイルがない場合、または開発者がカスタムプロファイルを使用する場合にのみ必要です。

接続プロファイルのデフォルトセットを基に作成するには、GET /api/v2/connection-profiles/templates エンドポイントを呼び出し、そのレスポンスをリクエスト本文で使用して接続プロファイルを作成します。

例:

GET /api/v2/connection-profiles/templates

エンドポイント リファレンス

POST /api/v2/connection-profile
{
    "name": "Okta OIN Express Configuration API",
    "identifier": "urn:auth0:express-configure"
}

エンドポイント リファレンス

​

OIN Express Configuration Client を作成する

指定したアプリケーションの Express Configuration 中に Okta が使用するサービスアプリケーションを作成します。このクライアントは、以下の例に示すプロパティを指定して作成する必要があります。

organization_require_behavior 属性は、以下のいずれかの値にカスタマイズできます。これらの値については、管理者のログインおよび同意の設定でも説明しています。

• pre_login_prompt: 資格情報の入力を求める前に、管理者の組織の入力を求めます。
  • post_login_prompt: 管理者の資格情報の入力を求めます。このオプションでは、PATCH /api/v2/connections/{id} エンドポイントを使用して、管理者アカウントを含む接続の enabled_clients プロパティに OIN クライアントのクライアントIDを追加します。

例:

POST /api/v2/clients
{
    "name": "Okta OIN Express Configuration",
    "app_type": "express_configuration",
    "organization_require_behavior": "pre_login_prompt",
    "client_authentication_methods": {
      "private_key_jwt": {
        "credentials": []
      }
    }
}

エンドポイントのリファレンス

​

SaaS アプリケーションのプロパティを設定する

OIN に公開する登録済みアプリケーションの express_configuration プロパティに設定値を指定します。例の値は、この統合で使用する有効な 接続プロファイル ID、ユーザー属性プロファイル ID、OIN クライアントアプリケーション ID、ログイン開始 URI、および Auth0 テナントのドメインに置き換えてください。

linked_clients 属性は、単一の統合で複数のアプリケーションを有効にする で説明されている設定に対応します。

enable_client 属性は、組織のログイン設定 で説明されている enabled_clients の設定に対応します。

enable_organization 属性は、作成した接続をその組織に割り当てない場合を除き、通常は true に設定する必要があります。Okta アプリインスタンスは引き続きその接続を管理できますが、Okta ユーザーは Auth0 組織のメンバーにはなりません。これを false に設定すると、接続をまたいで管理者アカウントの一致を維持する で説明されているケースで役立つことがあります。

例:

PATCH /api/v2/clients/{id}
{
  "express_configuration": {
      "admin_login_domain": "yourAuth0TenantDomain",
      "connection_profile_id": "yourConnectionProfileId",
      "enable_client": true,
      "enable_organization": true,
      "initiate_login_uri_template": "yourInitiateLoginUriTemplate",
      "okta_oin_client_id": "yourOinClientId",
      "user_attribute_profile_id": "yourConnectionProfileId",
"linked_clients": [ 
    { "client_id": "KJM86F2susguvsasSeAsIxxxxxxxxxxx" }, 
    { "client_id": "FIXwZCf5iUElvqy6eidlfxxxxxxxxxxx" }
 ] 
    }
}

エンドポイント リファレンス

​

公開鍵をアップロード

Okta チームから提供された公開鍵を、OIN クライアントアプリケーションの認証情報として追加します。

例:

POST /api/v2/clients/{oin_client_id}/credentials
{
  "credential_type": "public_key",
  "pem": "-----BEGIN PUBLIC KEY-----\nMIGf..."
}

エンドポイントのリファレンス

​

OIN クライアントアプリケーションにキーを割り当てる

Okta にアップロードした公開鍵を OIN サービスクライアントに割り当てます。yourCredentialId は、前の手順で取得した認証情報 ID に置き換えてください。

例:

PATCH /api/v2/clients/{oin_client_id}
{
 "client_authentication_methods": {
    "private_key_jwt": {
      "credentials": [
        {
          "id": "yourCredentialId",
        }
      ]
    }
  }
}

エンドポイントリファレンス

​

テナントの同意プロンプトをカスタマイズする

同意ページにスコープの詳細を表示するには、テナントの設定を更新します。これにより、付与される権限に関する情報が表示され、ユーザーエクスペリエンスが向上します。必須ではありませんが、推奨されます。

例:

PATCH /api/v2/tenants/settings
{ 
  "flags": { "use_scope_descriptions_for_consent": true } 
}

エンドポイントのリファレンス