目次
はじめに
「SAML入門」を手に取っていただき、ありがとうございます。本書では、SAML2.0で一般的に多く使用されるフローであるWeb Browser SSOのSP-initiatedとIdP-initiatedと呼ばれるものを中心に、SP側の目線でなるべく簡潔に解説します。
SAMLに対応してほしいといわれても、もう頭を抱える必要はありません。筆者自身も、何もわからない状態からもがき苦しみながらSAML SPを実装し、数年間サービスを運用してきました。そのつらい経験を踏まえて、SPを実装する上で今まで触れられることのなかった「どういう設計が必要か？」「何を気をつけなければならないか？」のエッセンスを詰め込みました。
SAMLはエンタープライズ用途では求められることが非常に多く、歴史もそれなりに長いものですが、実装する上で必要な体系的な情報はなぜかほとんどありません。OAuth、OIDC、FIDO2などの情報は溢れていますが、SAMLだけ仲間はずれです。
そんなSAMLを理解する助けになれば幸いです。
対象読者
・SAMLにはじめて触れる方
・SAMLによるシングルサインオンの仕組みが知りたい方
・過去に諦めてしまった方
・突如SAMLのSPを実装しないといけなくなってしまった方
・自社サービスをSAMLのSPに対応させたいけどやり方がわからない方
読み終わるとどうなるか
・SAMLの仕組みがなんとなくわかる
・SAMLの仕様がなんとなく読めるようになる
・SAMLのSP実装の第一歩を踏み出せる
この本は何の本ではないか
・SAMLのフローについてIdP側の役割はわかりますが、IdP側の実装に関する説明はありません。あくまでSP側の目線での説明になります
・本書ではSAML1.0、SAML1.1についての説明はありません。単にSAMLと記載しているときはSAML2.0を意味します
・XML署名の仕組みや暗号化についての説明はありません
免責事項
本書に記載された内容は、情報の提供のみを目的としています。したがって、本書の内容を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。本書の内容を用いた開発、製作、運用の結果については、著者はいかなる責任も負いません。
表記関係について
本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。
第1章 SAMLとは
SAML（Security Assertion Markup Language）とは、異なるインターネットドメイン間でユーザー認証を行うためのXMLをベースにした標準規格です。XML関連の標準化団体であるOASISによって2002年に策定され、2005年にはバージョン2.0となっています。現在ではバージョン2.0（SAML2.0）が主流です。
SAMLを利用することで企業のもつID基盤、たとえばAzure ADなどを利用して、複数のクラウドサービスへのシングルサインオンを実現します。つまり、ユーザーは自分の会社のID基盤に1度ログインするだけで、SAMLに対応しているさまざまなSaaSやウェブアプリケーションを利用することができるようになります。
このようなシングルサインオン環境を比較的簡単に構築できることから、エンタープライズ用途で求められることが多く、近年SaaSを中心に実装が広まっています。コロナ禍でSaaS導入は加速し、一企業で何十ものSaaSを使用することもあります。管理者の負担は増えるばかりです。詳しくは後述しますが、SAMLを使用することで管理者の工数削減に加え、セキュリティやガバナンスの強化を図ることが可能となります。そのため、SAMLが実装されていないからSaaSの導入が見送られてしまった、そもそも検討対象にすら上がらない、などということは日常茶飯事で、導入における非常に重要なファクターとなっている状況にあります。
同様にシングルサインオン環境を構築できるプロトコルとしてはOpenID Connectがありますが、コンシューマー向けではOpenID Connect、エンタープライズ向けではSAMLといった棲み分けがされている印象です。
1.1 企業がSAMLを使用するメリット
企業がSAMLを使用することで、主に次のようなメリットがあります。
・管理工数の削減
・セキュリティとガバナンスの強化
1.1.1 管理工数の削減
SaaSの導入をすると、次のような管理作業が発生します。
・入退社に伴うアカウントの作成や削除
・異動などに伴う各種権限設定の変更/管理
近年、SaaSを導入する企業は増えており、一企業でいくつものSaaSを利用することが当たり前になっています。導入しているSaaSがひとつやふたつ程度であれば大きく問題にはならないですが、いくつものSaaSを利用する昨今、このSaaSの管理に伴う作業は従業員数×導入しているSaaS数分となり、どんどん増えていきます。導入しているSaaSすべてで適切な権限設定がなされているか、不要なユーザーが存在しないかを定期的にチェックするのは、とても大変です。
たいていの企業では、情シスやIT部門が整備しているID基盤があり、そちらについては入退社時等アカウント管理が行われている状態だと思います。一方で、各部門で個別に導入されているSaaSまで管理が行き届いている企業は、どれだけあるのでしょうか？企業が管理するID基盤上（IdP）のアカウントを削除したとしても、各部門で個別に導入されているSaaSではアカウントが残ったままになっており、退職後もアクセスができる状態になっていることも珍しくありません。
SAMLによるシングルサインオンを利用することで、IdP上のアカウントを削除するだけで、それらと連携しているSaaSやアプリケーションにアクセスできないようにできます。たったひとつのアカウントを削除するだけですむのです。ユーザープロビジョニングの機能がないサービスでは、各サービス上のアカウント自体は個別で削除する必要はありますが、これだけでも入退社時のアカウント管理の負担はかなり軽くなります。また、ユーザーのパスワードロックやパスワード忘れによる対応などについても、IdPで一元管理とできるため、負担の軽減が見込めます。
1.1.2 セキュリティとガバナンスの強化
IdPはいうまでもなく、ID管理における豊富なセキュリティの機能を有しています。ユーザーに多要素認証を強制させたり、デバイス、ブラウザの制限等、さまざまなセキュリティ設定が可能です。SAMLによるシングルサインオンを設定すれば、SaaSに対してこれら豊富な機能を有したIdPの認証を一律で利用できます。
どのデバイスを用いてアクセスしたのか簡単に把握することができるようになり、特定のデバイスやスマートフォンからのアクセスは弾いたりすることも、IdP側でできるようになります。社員がデバイスを紛失した場合も、IdP上でそのデバイスでのログインを拒否するようにするだけで、連携しているSaaSすべてで紛失した端末からの不正アクセスを防ぐことができます。
つまり、SAMLで連携をしているSaaSすべてで、このようなセキュリティの強化や統制を取ることが可能となるのです。
これらの理由により、SaaSを導入する企業の管理者にとって、SAMLの有無は大きな関心事となっています。そんなSAMLを、本書を通して少しずつ理解していきましょう。