はじめに

SSO（シングルサインオン）の手法は様々なものがあり、SAMLはその中でも広く使われていますが、SAMLがどのように動作しているか、ご存じでしょうか？
　
このブログでは、SAMLを理解する上で重要な要素となる「SAMLアサーション」についてご紹介します。

SAMLとは？

SAMLとは、「Security Assertion Markup Language」の頭文字を取ったもので、XMLをベースにしたプロトコルです。Webアプリケーションを使用したSSO時に、アプリケーションが認証を外部の認証サービス(IdP)に委任する際に使用されます。
SAMLは、ユーザ（Webブラウザ）を通して、IdP(Identity Provider)とSP(Service Provider)が信頼しあうことで実現します。

では、SPは実際にどのようにIdPを信頼しているのでしょうか？
その答えは証明書です。次の章で具体的に見ていきましょう。

SAMLアサーションとは？

SAMLアサーションとは、ユーザの認証情報、属性、権限などの情報が記述されているメッセージです。IdPがユーザの認証及び属性や権限の検証を行った上でSAMLアサーションを発行し、SPがSAMLアサーションを受信します。
　
SPがSAMLアサーションを受信する時、IdPを信頼する必要があります。その際に、SPは受信したSAMLアサーションが正しい証明書を使って署名されているかどうかを確認します。
　
ここでSAMLアサーションの署名が正しいことを確認するために、SPが事前にIdPの証明書を持っている必要があります。

SAMLアサーションに含まれる情報は下記の3つです。

• 認証アサーション（authentication）：認証された時刻や場所などの情報
• 属性アサーション（attribution）：ユーザの名前、年齢などの属性情報
• 認可決定アサーション（authorization）：ファイルへのアクセス権限など、ユーザの権限に関する情報

OktaのSAMLアサーション

実際にOktaのSAMLアサーションを、Google ChromeのSAML Tracerを使って観察してみました。
SAML Tracerで確認できるSAMLアサーションは下図のものになります。

IdP-initiatedでSlackにアクセスしたときのSAMLアサーション

「saml2:AuthnStatement」の記述が認証アサーションであり、「saml2:AttributeStatement」の記述が属性アサーションです。
　
OktaのSAMLアサーションを見ると、認可決定アサーションが含まれておらず、認証アサーションと属性アサーションが含まれていることがわかります。
　
下図の部分がSAMLアサーションの中の認証アサーションの部分です。「2021-11-18T23:43:29.317Z」の箇所から、ユーザを認証した時間がわかります。
また、「urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport」の記載があるので、IdPがパスワードを使ってユーザを認証したことがわかります。

属性アサーションには、メールアドレス、氏名、ユーザ名の情報が含まれていることがわかります。　

SAMLアサーションに含まれる情報の中で重要な情報の一つにNameIDがあります。

SAMLで認証を行うには、IdPとSPがどのようにユーザを定義しているのかという情報が必要です。
例えば、ユーザを特定するためにSPがメールアドレスを使用しているのに対して、IdPがユーザIDを使用していた場合、メールアドレスとユーザIDとしてのメールアドレスが異なっていた時にSP側とIdP側のユーザの紐づけができず、認証できません。
　
NameIDは、IdPとSPがユーザの定義方法を伝えるために使用されます。
　
Name IDのフォーマットは、下記のように様々なものがあります。

• Unspecified
  記述：urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
• メールアドレス
  記述：urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
• X.509 Subject Name
  記述：urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
• Windows Domain Qualified Name
  記述：urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
• Kerberos Principal Name
  記述：urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
• Persistent Identifier
  記述：urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
• Transient Identifier
  記述：urn:oasis:names:tc:SAML:2.0:nameid-format:transient

OktaのSAMLアサーションには「urn:oasis:names:tc:SAML:2.0:nameid-format:persistentの記載があるので、Persistent IdentifierのNameIDフォーマットを使用していることがわかります。
Persistent Identifierは、１つのユーザに対して同じ識別子を常に使う、永続識別子でユーザを定義しています。
すなわち、IdPとSP間でユーザを紐づけるための、ユーザ固有の識別子がOktaには存在します。

まとめ

今回はOktaのSAMLアサーションを観察してみましたが、いかがでしたでしょうか？
IdP-initiatedでSlackにアクセスしたときのSAMLアサーションをご紹介しましたが、SPinitiatedでアクセスした時や、別のSPにアクセスした時など、状況が異なるとSAMLアサーションに記載される情報も異なります。

SAMLについて学ぶ際には、実際に送信されるSAMLアサーションを観察してみると、面白いと思います。