Security Assertion Markup Language (SAML、発音は SAM-el、/ˈsæməl/) [1]は、特にアイデンティティプロバイダとサービスプロバイダの間で認証および認可データを交換するための公開標準である。SAMLは、セキュリティアサーション(サービスプロバイダがアクセス制御の決定を行うために使用するステートメント)のための XML ベースのマークアップ言語である。SAMLはまた以下のものでもある:
SAMLが対応する重要なユースケースの1つは、ウェブブラウザのシングルサインオン (SSO) である。シングルサインオンは、セキュリティドメイン内では比較的簡単に達成できる(たとえば、クッキーを使用する場合など)、しかしセキュリティドメインを越えてSSOを拡張することはより難しく、非互換のプロプライエタリ技術の増加をもたらした。SAML Web ブラウザ SSO プロファイルは、相互運用性を促進するために指定および標準化された[2]。
同様の技術として Securant Technologies社が発表したAuthXMLとNetegrity社 が発表したS2MLという規格があり、SAML はこの二つの規格を統合したものである。
2016年現在の最新版は2005年3月に策定されたSAML v2.0である[3]。
SAMLの標準では、認証、属性、権限の認可をXMLでアサーション(assertion, 直訳:表明)する方法と、これらの情報を伝送するためのプロトコルとに関する文法と意味論を定義している[4]。
アサーション(assertion, 直訳:表明)は、SAMLにおける最も基礎的な概念の一つで、これはユーザの認証情報、属性、ユーザへの権限の認可といったセキュリティ情報をXML文法で記載したものである[4][5]。複数のエンティティの間でアサーションをやり取りする事で前述したシングルサインオンやID連携を実現する。
SAMLの標準はアサーションの詳細と、アサーションを伝送するためのプロトコルとに関する文法と意味論を定義している[4]。
アサーションはサブジェクト(subject)に対するステートメント(statements)という形式でセキュリティ情報を記述できる[5]。
ここでサブジェクトは何らかの「セキュリティ領域」(security domain)にいるエンティティで、アサートされる対象である[6]。サブジェクトは人間であっても会社やコンピューターなどでもよい[6]。
ステートメントには以下の三種類がある:
SAMLのユースケースでは最低限以下の2つのパーティが関わる:アサーションを発行するSAMLアサーションパーティ(SAML asserting party、直訳:SAML表明当事者)と、アサーションを受信してそれを用いるSAMLリライングパーティ(SAML relying party、直訳:SAML依拠当事者)という[6]。SAMLアサーションパーティはSAMLオーソリティ(SAML authority、直訳:SAML権限者)ともいう[6]
多くのユースケースではさらにユーザが関わる。このユーザ自身がSAMLアサーションパーティであることもある。
上述の2つのパーティやユーザ、もしくはそれ以外のパーティがアサーションの送信を他のパーティに要求するとき、その要求するパーティをSAMLリクエスター(SAML requester、直訳:SAML要求者)といい、それに応じてアサーションを送信するパーティをSAMLレスポンダー(SAML responder、直訳:SAML応答者)という[6]。
SAMLの関係者は様々なロール(役割)を担う。例えばシングルサインオンにSAMLを使う場合にはアイデンティティプロバイダというロールとサービスプロバイダというロールがある[6]。
シングルサインオンは、ユーザが一度認証を受けるだけで複数のサービスやアプリケーションを利用できるようになる仕組みのことである。
SAMLをシングルサインオンで用いるには、ユーザが最初に認証を受けるサイトがアイデンティティプロバイダ(identity provider、 IdP)というロールを担う[7]。そのサイトでのユーザの認証情報やログインセッションのようなセキュリティ情報をセキュリティコンテクスト(security context)と呼ぶ[7]。
一方、IdPにおけるユーザの認証情報を信頼してサービスやアプリケーションを提供するサイトはサービスプロバイダ(service provider、SP)というロールを担う[7]。
IdPとSPは事前に両者で用いるユーザIDを対応付けることで、IdPのどのユーザがSPのどのユーザと対応しているかを明らかにしておく(すなわちID連携しておく)必要がある[7]。
ユーザがIdPで認証を受けたあと、SPのサービスを利用しようとすると、IdPはユーザのセキュリティ・コンテクストからアサーションを作成し、アサーションをSPに送る[7]。
アサーションには例えばユーザに関する以下の情報が載っている[7]:
上で説明したユースケースではユーザはSPにアクセスする前にIdPに認証を受けるフロー(IdP-initiated flow)を説明したが、逆にSPにアクセスした後にIdPから認証を受けるフロー(SP-initiated flow)のほうがより一般的である。というのも検索サイトやブックマークなどから直接SPのサイトにアクセスした場合は、IdPからの認証を受ける前にユーザがSPにアクセスする事になるからである。このためSAMLは両方のフローに対応している[7]。
![]() | この節の加筆が望まれています。 |
saml-tech-overview 3.3 Identity Federation Use Caseを参照。