甘めな技術。

セキュリティ多めの甘めな技術ブログ

SAML認証について

リレーブログ

はじめに

こんにちは、リレーブログ！

前回はこちら。次回はあちら。

今回のテーマはSAML認証です。

セキスペでも頻出の奴ですね（ちょうど令和4年度春試験にも出ていました）。

それでは書いていこうと思います！

SAML認証とは

SAML認証とは文字通りSAML(Security Assertion Markup Language)を使用した認証方式です。SAMLとはIDやパスワードなどの認証情報を安全に交換するためのXML仕様のことで、OASISによって策定されました。

SOAPをベースとしており、複数のドメインにまたがるSSO（シングルサインオン）やID連携に利用されています。

SSOについては以前にもリレーブログのテーマになっていました。

qwerty11.hatenablog.com

今回はこの記事内にもあるSAML認証について深堀していく形です。

SAMLの形式

まずSAMLでは認証・認可される対象の事をサブジェクトと呼びます。これは人間以外（会社など）も当てはまる場合があります。

またSAMLで扱う情報はアサーションと呼ばれ、サブジェクトに対するステートメントの形式で記述されます。ステートメントは以下の3つです。

次に示すのはアサーションの一例（のステートメントの部分）です。

<saml:Assertion 
   ID="id0987654321_" 
   IssueInstant="2022-04-23T20:00:12.345Z" 
   Version="2.0">
   
   <saml:AuthnStatement AuthnInstant="2022-04-23T20:00:10.345Z">
      <saml:AuthnContext>
         <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
         </saml:AuthnContextClassRef>
      </saml:AuthnContext>
   </saml:AuthnStatement>

   <saml:AttributeStatement>
      <saml:Attribute Name="FirstName">
         <saml:AttributeValue xsi:type="xs:string">
            Taro
         </saml:AttributeValue>
      </saml:Attribute>
   </saml:AttributeStatement>

   <saml:AuthzDecisionStatement
      Decision="Permit"
      Resource="https://www.example.com">

      <saml:Action>
          Read
      </saml:Action>
   </saml:AuthzDecisionStatement>

</saml:Assertion>

上から認証、属性、認可決定ステートメントです。

認証ステートメント(AuthnStatement)
  • AuthnInstant：認証が行われた時刻
  • AuthnContextClassRef：認証方法を示すAuthnContextClassを識別するURI

上記の場合、2022年4月23日20時00分10秒345に認証されHTTPSでパスワード認証が使われたことを示しています。

属性ステートメント(AttributeStatement)
  • Name：属性の名前
  • AttributeValue：属性の値

上記の場合、サブジェクトのFirstNameという属性がTaroであることを示しています。

認可決定ステートメント(AuthzDecisionStatement)
  • Decision：アクセス要求に対する結果
  • Resource：アクセス権限が求められているリソースのURI
  • Action：求められているアクション

上記の場合、https://www.example.com に対するReadが認可されたことを示しています。

なおAuthzDecisionStatementはSAML2.0の時点で仕様凍結されています。

代わってより高度で柔軟なアクセス制御が可能なXACML(eXtensible Access Control Markup Language)がOASISによって標準化されています。

これらはアサーション部分を切り出したものです。 実際の認証ではこれらの他にもより多くの情報がやり取りされます。

SAMLによるSSO

SAMLによるSSOではユーザのアカウント情報の管理及び認証を行うIdP(Identity Provider)と、IdPを信頼しユーザにサービスを提供するSP(Service Provider)で構成されます。

IdPとSP間でSAMLRequestとSAMLResponseを送受信するために次のような方法が取られます。

Artifactとはアサーションを参照するための値です。アサーションのサイズが大きいことから、アサーションそのものではなくArtifactを用いるようにしたのがHTTP Artifactバインディングです。

次に示すのはSAML2.0によるSSOシステムの認証手順例です。

  1. ユーザがSPにアクセス要求
  2. SPはSAMLRequestメッセージを発行してIdPにユーザをリダイレクトさせ認証確認
  3. 認証済みの場合は5に進む
  4. ユーザはIdPにIDとパスワードを送信し、IdPは初期認証を実施し成功したら次に進む
  5. IdPは、アサーションを生成し、ディジタル署名を付したSAMLResponseメッセージを発行してSPにリダイレクトする
  6. SPはSAMLResponseメッセージのディジタル署名やアサーションの内容を検証する
  7. 問題がなかった場合、SPはユーザにサービスを提供する。その後、このユーザはIdPとID連携をしている他のSPにも再度認証を受けずにアクセス可能となる

まとめ

簡単にですがSAML認証ついてまとめました。

時間がなくてまとめられませんでしたが、SAML認証のライブラリにも勿論脆弱性はあります（CVE-2021-28091など）。

何にでも言えることですが、ライブラリ等を過信しすぎず脆弱性管理をしっかりしないとインシデントの原因になってしまいます。

あたりまえですけど仕組みをしっかり理解して適切に運用することが大切ですね！

参考文献

Security Assertion Markup Language (SAML) V2.0 Technical Overview

Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0

アイデンティティ管理技術解説(IPA)

Help And Training Community

情報処理教科書 情報処理安全確保支援士 2022年版