問題

SAML 認証の使用時、モバイル アプリにログインできない。次のエラーがログに記録される。

[c.a.p.a.i.web.filter.ErrorHandlingFilter] Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN_69459a17-0211-427e-9f0f-9c7a1779009e while no InResponseTo was expected

詳細

SAML の概要とその仕組み

セキュリティ アサーション マークアップ言語 (SAML) とは、ID プロバイダー (IdP) がサービス プロバイダー (SP) に認証情報を渡すことを可能にするオープン スタンダードです。SAML のトランザクションでは、ID プロバイダーとサービス プロバイダー間の標準化された通信に、拡張可能なマークアップ言語 (XML) が使用されます。

それぞれの言語には、次のようなさまざまな種類の認証プロセスがあります。

• Redirect Binding を使用した SP-initiated SSO では、SP から IdP に <AuthnRequest> メッセージを渡し、POST Binding を使用して IdP から SP に <Response> メッセージを渡します。

• POST Binding を使用した SP-initiated SSO では、<AuthnRequest> メッセージと Artifact Binding により <Response> メッセージを転送します。

• POST Binding を使用した IDP-initiated SSO では、<Response> メッセージを IdP から SP に転送します。<AuthnRequest> はまったく使用されません。

最後に、SP-initiated SSO: Redirect/POST Bindings を使用した、Jira と Azure SSO の間の SSO 認証プロセスを確認します。

1. ユーザーが、特定の URL から Jira にアクセスを試みます。ユーザーには、有効なログイン セッションがありません (例: セキュリティ コンテキスト)。サービス プロバイダーにより、ユーザーが要求した URL が保存されます。
2. アプリにより、ユーザーを認証するための ID プロバイダーが特定されます。

3. サービス プロバイダーにより、ユーザーのブラウザに 302 または 303 のリダイレクト コードが返されます。HTTP Location ヘッダーには、SSO サービスの URL が含まれ、URL 変数 SAMLRequest により、リクエスト本文 <AuthnRequest> が渡されます。例:

   <samlp:AuthnRequest
   xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
   ID="id6c1c178c166d486687be4aaf5e482730"
   Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z"
   xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
   <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.example.com</Issuer>
   </samlp:AuthnRequest>

   その後ブラウザにより、受信されたリダイレクトが処理され、ID プロバイダーの URL に HTTP GET が発行され、SAMLRequest が渡されます。

4. SSO サービスにより、ユーザーが有効なログイン セッションを持っているかどうかがチェックされます。このログイン セッションは、サービス プロバイダー (Jira) の AuthnRequest に渡された指定の認証タイプに準拠する必要があります。このセッションが見つからない場合、ユーザーはログインとパスワードを使用して ID プロバイダーで認証する必要があります。その結果、ユーザーは ID プロバイダーで認証され、そこでセキュリティ コンテキストが作成されます。

5. ID プロバイダーの SSO (シングル サインオン) サービスにより、このユーザーのセキュリティ コンテキストを含むアサートを持つ SAML <Response> を生成します。SAMLResponse ボディは <samlp:Response> 要素の base64 エンコーディングで転送されます。サインオンの試行が成功した場合の応答は、次の例のようになります。 

   <samlp:Response ID="_a4958bfd-e107-4e67-b06d-0d85ade2e76a" Version="2.0" IssueInstant="2013-03-18T07:38:15.144Z" Destination="https://example.com/identity/inboundsso.aspx" InResponseTo="id758d0ef385634593a77bdf7e632984b6" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
     <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer>
     <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
       ...
     </ds:Signature>
     <samlp:Status>
       <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
     </samlp:Status>
     <Assertion ID="_bf9c623d-cc20-407a-9a59-c2d0aee84d12" IssueInstant="2013-03-18T07:38:15.144Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
       <Issuer>https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer>
       <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
         ...
       </ds:Signature>
       <Subject>
         <NameID>Uz2Pqz1X7pxe4XLWxV9KJQ+n59d573SepSAkuYKSde8=</NameID>
         <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
           <SubjectConfirmationData InResponseTo="id758d0ef385634593a77bdf7e632984b6" NotOnOrAfter="2013-03-18T07:43:15.144Z" Recipient="https://example.com/identity/inboundsso.aspx" />
         </SubjectConfirmation>
       </Subject>
       <Conditions NotBefore="2013-03-18T07:38:15.128Z" NotOnOrAfter="2013-03-18T08:48:15.128Z">
         <AudienceRestriction>
           <Audience>https://www.example.com</Audience>
         </AudienceRestriction>
       </Conditions>
       <AttributeStatement>
         <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
           <AttributeValue>testuser@example.com</AttributeValue>
         </Attribute>
         <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
           <AttributeValue>3F2504E0-4F89-11D3-9A0C-0305E82C3301</AttributeValue>
         </Attribute>
         ...
       </AttributeStatement>
       <AuthnStatement AuthnInstant="2013-03-18T07:33:56.000Z" SessionIndex="_bf9c623d-cc20-407a-9a59-c2d0aee84d12">
         <AuthnContext>
           <AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
         </AuthnContext>
       </AuthnStatement>
     </Assertion>
   </samlp:Response>

6. ブラウザからサービス プロバイダー (Jira) へ POST リクエストを発行して SAMLResponse を渡します。サービス プロバイダーにより <Response> の内容がチェックされ、このユーザーの新しいローカル セキュリティが作成されます。

セッション アフィニティとは

クッキー ベースのセッション アフィニティ機能は、ユーザー セッションを同じサーバー上で維持したい場合に便利です。Azure Application Gateway では、ユーザー セッションを維持するためにゲートウェイで管理されたクッキーを使用しています。ユーザーが最初のリクエストを Application Gateway に送信すると、セッションの詳細を含むハッシュ値を使用して、応答にアフィニティ クッキーが設定されます。これにより、アフィニティ クッキーを含む後続のリクエストは、スティッキー セッションを維持するために同じバックエンド サーバーにルートされます。

有効にすると、Azure Application Gateway は次のことを行います。

• クライアントが最初のリクエストを行うと、Azure Application Gateway は ApplicationGatewayAffinity とApplicationGatewayAffinityCORS クッキーを設定します。クッキーは、リクエストの転送先となるオリジンをエンコードします。

• クッキーが有効である期間、そしてオリジンのサーバーが正常である限り、同じクッキーを使った後続のリクエストは、そのオリジンに転送されます。

Chromium ブラウザの v80 のアップデートにより、SameSite 属性のない HTTP クッキーを、SameSite=LAX として扱うことが義務付けられました。CORS (Cross-Origin Resource Sharing) リクエストの場合、クッキーをサードパーティのコンテキストで送信する必要がある場合は、SameSite=None; Secure 属性を使用する必要があり、HTTPS 経由のみで送信する必要があります。
この変更に対応するため、2020 年 2 月 17 日から、Application Gateway (すべての SKU タイプ) は、既存の ApplicationGatewayAffinity クッキーに加えて、ApplicationGatewayAffinityCORS と呼ばれる別のクッキーを挿入します。ApplicationGatewayAffinityCORS クッキーには、クロスオリジン リクエストの場合でもスティッキーセッションが維持されるように、さらに 2 つの属性 ("SameSite=None; Secure") が追加されています。

原因

1. この問題は、ロードバランサーが、ローカル セッションに ID 属性が保存されていない別のノードに SAML レスポンスをリダイレクトすることで発生します。SP が SAMLRequest を送信する (上記のステップ 2) と、リクエストの ID 属性もローカル セッションに保存されます。SP が SAML レスポンスを受信する (上記のステップ 6) と、InResponseTo 属性が保存した ID と等しいことが確認されます。セッションに ID 属性が保存されていないため、ID が同じかどうかは確認できません。その結果、ログに例外が書き込まれます。
   
   
   • 以下のパッケージのデバッグ レベルを有効にすることで、SAML セッションが一方のノードで作成されて応答がもう一方のノードに送信されていることを確認できます。
     • com.onelogin
     • com.atlassian.plugins.authentication
2. JRASERVER-69598 - Unable to log in with SAML SSO when user has special character in name というバグも、この問題の原因である可能性があります。これは、ユーザー アカウントに特殊文字 (改行なしスペース「& #xA 0」などの UI には表示されない 16 進数コードを含む) が含まれている場合に発生します。
3. SSO プラグインが最新版ではありません。
4. お知らせバナー、カスタム フィールドの説明、またはその他の方法を介して DOM に挿入されたカスタムの JavaScript コードも、この問題の原因となる可能性があります。

ソリューション

原因 1

この問題の原因として考えられるのは次のとおりです。

1. ご利用のファイアウォールまたはプロキシにより、Azure Application Gateway がリクエストを処理するノードを決定するために使用する ApplicationGatewayAffinityCORS クッキーが削除されます。

2. HTTPS アドレスがない (ApplicationGatewayAffinityCORS は HTTPS 経由だけで送信されます）。これは、設定ミス (例: HTTP から HTTPS へのリダイレクトがない) か、ユーザーが HTTP アドレスを入力したことが原因です。
3. セッション アフィニティがありません。
4. ApplicationGatewayAffinityCORS の送信を妨げているその他の理由。
5. ここで説明されている SameSite クッキーの問題が発生しています。

原因 2

影響を受けているユーザー名から特殊文字を削除し、HAR ファイルを収集する必要があるかもしれません。これにより、SAMLResponse を分析することで、ユーザー名と無効な文字が表示されるはずです。

原因 3

SSO プラグインをアップグレードします。

このプラグインは複数の製品 (Jira、Confluence、Bitbucket など) で使われているため、ご利用のアトラシアン製品でサポートされるプラグイン バージョンに応じて、SSO for Atlassian Server and Data Center プラグインのバージョン 3.2.5/4.0.8/4.1.5 以降をインストールするか、それらにアップグレードします。アプリがインストールにバンドルされていた場合は、アトラシアン サポートから特段の依頼がない限りアプリを更新する必要はありません。