SAML IDプロバイダー起点のシングルサインオンを構成する

SAMLフェデレーションをセットアップする手順の多くは、サービスプロバイダーによって開始されるシングルサインオン（SSO）から始まります。サービスプロバイダーは、認証の目的でユーザーをIDプロバイダー（IdP）にリダイレクトします。このプロセスは、消費者向けのシナリオでよく使用されます。

ただし、エンタープライズのシナリオでは、サービスプロバイダーではなくIdPによってSSOが開始されることが一般的です。たとえば、エンタープライズは、ユーザーがポータルにサインオンした後に正しいアプリケーションに移動できるようにポータルをセットアップする場合があります。

IdP起点フローにはセキュリティリスクがあるため、お勧めできません。可能な限り、SP起点フローの使用をお勧めします。

IdP起点SSOを有効にする前に、必ずリスクについて理解しておいてください。このシナリオでは、Auth0がIdPから一方的な応答を受信し、アプリケーションがAuth0から一方的な応答を受信します。どちらのエンティティも、ユーザーがフローを開始したことを確認できません。このため、このフローを有効にすると、ログインCSRF攻撃にさらされる可能性が高まり、攻撃者は正当なユーザーをだまして、攻撃者のIDを使って無意識のうちにアプリケーションにログインさせることができます。

OpenID Connect（OIDC）は、IdP起点フローの概念をサポートしていません。そのため、Auth0は、（SAML接続からの）SAML IdP起点フローをアプリケーションのOIDC応答に変換できる機能を提供しますが、OIDC/OAuth2プロトコルを適切に実装しているアプリケーションは要求されていない応答を拒否します。

OIDCアプリケーションを使用する場合、最良のオプションは、アプリケーションにログインエンドポイントを作成させることです。このエンドポイントの唯一の目的は、IdP（Auth0テナント）へのリダイレクトを開始することです。

複数のIdPを使用する場合は、ログインエンドポイントがIDプロバイダーに固有であるか、ワークフローを開始するIdPを識別するパラメーターを受け入れられることを確認してください。

別のアプローチとして、ユーザーがアプリケーションでログインフローを開始することもできます。

IdP起点SSOを使用する場合は、必ずポストバックURLに接続パラメーターを含めてください。

https://{yourDomain}/login/callback?connection={yourConnectionName}

Organizations機能を使用している場合は、必要に応じて、目的の組織の組織IDを含む、次の組織パラメーターを含めることもできます。

https://{yourDomain}/login/callback?connection={yourConnectionName}&organization={yourCustomersOrganizationId}

アプリケーションが、Lock またはAuth0.jsを使用して認証結果を処理するシングルページアプリケーションの場合は、IdP起点フローを許可することを明示的に示す必要があり、その結果、アプリケーションがログインCSRF攻撃にさらされる可能性があります。

Auth0.jsを使用している場合は、ライブラリーのwebAuth.parseHashを更新し、フラグ __enableIdPInitiatedLoginをtrueに設定する必要があります。

var data = webAuth.parseHash(
      {
        ...
        __enableIdPInitiatedLogin: true
        ...
      }

Lock を使用する場合は、コンストラクターに送信されるオプションのパラメーターを使用してフラグを含めることができます。

const lock = new Auth0Lock(clientID, domain, options)

フラグ自体は次のとおりです：

var options = { _enableIdPInitiatedLogin: true };

enableIdPInitiatedLoginフラグの前に、Lockで使用する場合は1つのアンダースコア、auth0.jsライブラリーで使用する場合は2つのアンダースコアがそれぞれ付くことに注意してください。

1. ［Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］の順に移動し、［SAMLP Identity Provider（SAMLP IDプロバイダー）］を選択します。

2. ［Settings（設定）］で、IdP起点SSOの構成を確認できます。

   

• IdP-initiated SSO Behavior（IdP起点SSOの動作）：このオプションを使用すると、SAML接続に対してIdP起点のログインを有効にすることができます。［Accept Requests（要求を受け入れる）］を選択し、すべての必須フィールドに値を入力します。

• Default Application（デフォルトのアプリケーション）：IdP起点のログインが成功すると、これがユーザーをルーティングするアプリケーションとなります。この設定には、この接続で有効になっている利用可能なアプリケーションが表示されます。IdP起点でユーザーにログインさせるアプリケーションをドロップダウンから選択します。1つのSAML接続につき、IdP起点のログインに対して選択できるアプリケーションは1つだけです。

• Response Protocol（応答プロトコル）：これは、選択したデフォルトのアプリケーションの接続に使用するプロトコルです。通常、アプリケーションはOpenID Connectプロトコルを使って構成されます（上記を参照）。ただし、アプリケーションにSAML2 Webアプリアドオンを構成しており、SAMLアサーションをルーティングしたい場合は、SAMLを選択する必要があります。有効なSAMLアサーションがポストバックURLに渡されると、Auth0は、選択された応答プロトコルを使用して、構成されたデフォルトのアプリケーションの最初に許可されたコールバックURLにログイン応答を送信します。OIDCを使用する場合、クエリ文字列フィールドを使用してこのプロトコルを変更し、redirect_uriを指定することができます。

• Query String（クエリ文字列）：クエリ文字列のオプションは、OpenID Connectプロトコルが使用されるときの動作をカスタマイズするのに役立ちます。クエリ文字列を使用して、パラメーターの設定に類似した複数のオプションを設定することができます。以下のように設定できます。

  設定	説明
  redirect_uri	IdP起点のログインが完了したら、要求がアプリケーションの__Allowed Callback URLs（許可されているCallback URL）__にリスト表示されている最初のURLにリダイレクトされます。ただし、redirect_uriを設定している場合、IdPはこのURLにリダイレクトします。これにより、ワイルドカードを使用する設定されたサブドメインスキームがあり、ある特定のサブドメインのみにリダイレクトしたい場合などのケースに柔軟性を追加します。
  scope	送信されたIDトークンのスコープを定義します。複数のスコープを設定できます。
  response_type	SPAの暗黙付与フローのトークンを設定します。通常のWebアプリに対して認証コード付与フローのコードを設定できます。

  IdP起点フローでは、Callback URLのドメインが未検証の場合、Auth0サーバーはトークンにあるスコープを削除します。Auth0で未検証のドメインとして定義されているのは、localhostと127.0.0.1のみです。どちらかをCallback URLとして使用すると、/userinfoエンドポイントからのトークンは空の応答を返します。要求したスコープのあるトークン応答を取得するには、検証済みのドメインを使用します。

  クエリ文字列の例： redirect_uri=https://jwt.io&scope=openid email&response_type=token

IdP起点SSOでアプリケーションをDefault Application（デフォルトのアプリケーション）として選択する場合で、かつそのアプリケーションがテナントのドロップダウンリストの最初の100個のアプリケーションに含まれていない場合は、Management APIを使用してそのアプリケーションを選択する必要があります。パッチを実行する必要があります。

{
"options": {
"signInEndpoint": "yourIdpSignInUrl",
"idpinitiated": {
"client_id": "yourClientId",
"client_protocol": "saml",
"client_authorizequery": ""
},
"signingCert": "[copied-from-GET]"
}
}

• 証明書やキーの文字列表現で作業する