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

SAML IDプロバイダー起点のシングルサインオン（SSO）を設定する方法について説明します。

SAMLフェデレーションの設定手順の多くは、サービスプロバイダーが開始するシングルサインオン (SSO) から始まります。サービスプロバイダーは、認証のためにユーザーをアイデンティティプロバイダー (IdP) にリダイレクトします。このプロセスは、一般にコンシューマー向けのシナリオで使われます。

ただし、エンタープライズのシナリオでは、サービスプロバイダーではなく、IdP が SSO を開始するケースから始めることも少なくありません。たとえば、企業がポータルを用意し、ユーザーがそのポータルにサインオンした後に正しいアプリケーションへ移動できるようにする場合です。

​

リスクと注意事項

IdP 主導 フローにはセキュリティ上のリスクがあるため、推奨されません。可能な限り、SP-Initiated フローを使用することを推奨します。

IdP 主導 SSO を有効にする前に、リスクを十分に理解してください。このシナリオでは、Auth0 は IdP からの未承諾のレスポンスを受け取り、アプリケーションは Auth0 からの未承諾のレスポンスを受け取ります。どちらも、ユーザー自身がそのフローを開始したことを確認できません。そのため、このフローを有効にすると、攻撃者が正当なユーザーをだまして、攻撃者のアイデンティティで気付かないうちにアプリケーションへログインさせる Login CSRF attack を受けるおそれがあります。

​

OpenID Connect の IdP 起点フロー

OpenID Connect (OIDC) は、IdP 起点フローという考え方をサポートしていません。したがって、Auth0 では SAML IdP 起点フロー (SAML 接続からのフロー) をアプリケーション向けの OIDC レスポンスに変換できますが、OIDC/OAuth 2.0 プロトコルを適切に実装しているアプリケーションは、要求していないレスポンスを拒否します。

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

複数の IdP を使用する場合は、ログイン エンドポイントをアイデンティティプロバイダーごとに用意するか、どの IdP がワークフローを開始したのかを識別するためのパラメーターを受け取れるようにしてください。

別の方法として、ユーザーがアプリケーション側からログインを開始するようにすることもできます。

​

Post-back URL

IdP 主導 SSO を使用する際は、Post-back URL に connection パラメーターを必ず含めてください。

Organizations機能を使用している場合は、必要に応じて、対象の組織の組織IDを含む organization パラメーターを指定できます:

この方法でユーザーが正常にログインするには、対象の接続がその組織で有効になっている必要があります。さらに、有効にした接続に対して自動メンバーシップを設定するか、ユーザーがその組織のメンバーシップを持っていることを確認する必要があります。

​

Lock/Auth0.js

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

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

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

Lock を使用している場合は、コンストラクターに渡す options パラメーターでこのフラグを指定できます。

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

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

var options = { _enableIdPInitiatedLogin: true };

enableIdPInitiatedLogin フラグは、Lock で使用する場合は先頭にアンダースコアが 1 つ付き、auth0.js ライブラリで使用する場合はアンダースコアが 2 つ付く点に注意してください。

​

IDP-initiated SSO を設定する

1. Dashboard > Authentication > Enterprise に移動し、SAMLP Identity Provider を選択します。

2. 設定 で、IdP 主導 SSO の構成を確認できます。

   

• IdP-initiated SSO Behavior: このオプションでは、SAML 接続での IdP 主導 ログインを有効にできます。Accept Requests を選択し、必要なフィールドをすべて入力します。
• Default Application: IdP 主導 ログインが成功すると、ユーザーはこのアプリケーションに送られます。この設定には、この接続で有効になっている利用可能なアプリケーションが表示されます。ユーザーに IdP 主導 でログインさせるアプリケーションをドロップダウンから選択します。SAML 接続ごとに、IdP 主導 ログイン用に選択できるアプリケーションは 1 つだけです。
• Response Protocol: これは、選択した Default Application に接続するために使用されるプロトコルです。通常、アプリケーションは OpenID Connect プロトコルで構成されています (上記を参照) 。ただし、アプリケーションに SAML2 Web App アドオンを構成していて、SAML アサーションをルーティングしたい場合は、SAML を選択する必要があります。有効な SAML Assertion が postback URL に渡されると、Auth0 は選択したレスポンスプロトコルを使って、構成済みのデフォルトアプリケーションの最初の許可済みコールバック URL にログインレスポンスを送信します。OIDC を使用している場合は、クエリ文字列フィールドで redirect_uri を指定することで、これを変更できます。
  • アプリケーションに構成されたコールバック URL に 複数のカスタムドメイン (MCD) のプレースホルダーが含まれている場合、システムは、IdP からの最初のリクエストを受信した postback URL のカスタムドメインに対応するメタデータ値を使って、その値を動的に設定します。詳しくは、Multiple Custom Domains を参照してください。
• Query String: OpenID Connect プロトコルを使用する場合、クエリ文字列オプションを使って動作をカスタマイズできます。query string でパラメーターを設定するのと同じように、複数のオプションを指定できます。設定できる内容は次のとおりです。

設定	説明
redirect_uri	IdP 主導 ログインが完了すると、リクエストはアプリケーションの Allowed Callback URLs に一覧表示されている最初の URL にリダイレクトされます。ただし、redirect_uri を設定すると、IdP はこの URL にリダイレクトします。これにより、ワイルドカードを使った固定のサブドメイン構成があり、特定の 1 つのサブドメインにだけリダイレクトしたい場合などにも柔軟に対応できます。
scope	送信される ID トークンのスコープを定義します。複数のスコープを設定できます。
response_type	SPA 用の Implicit Grant Flow では token を設定できます。regular web apps 用の Authorization Code Grant Flow では code を設定できます。

IdP 主導 フローでは、コールバック URL が未検証のドメインである場合、Auth0 サーバーはトークン内のスコープを削除します。Auth0 では、未検証のドメインとして localhost と 127.0.0.1 だけを定義しています。これらのいずれかをコールバック URL として使用すると、/userinfo エンドポイントからのトークンは空のレスポンスを返します。リクエストしたスコープを含むトークンレスポンスを取得するには、検証済みドメインを使用してください。

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

​

アプリケーションのドロップダウンリストは100件までに制限されています

IdP 主導 SSO で Default Application としてアプリケーションを選択する場合、そのアプリケーションがテナントのドロップダウンリストの先頭100件に含まれていなければ、Management API を使用してそのアプリケーションを選択する必要があります。PATCH を実行する必要があります:

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

​

詳細はこちら

• 証明書とキーをString形式で扱う