Security Assertion Markup Language

SAMLから転送)

Security Assertion Markup Language(セキュリティ アサーション マークアップ ランゲージ、略称SAML、読み: sam-el[1])はOASISで標準として策定されたマークアップ言語で、主にシングルサインオンID連携で利用されている[2]。メッセージの送受信にはHTTPSOAPが使われる[3]

概要編集

同様の技術として Securant Technologies社が発表したAuthXMLとNetegrity社 が発表したS2MLという規格があり、SAML はこの二つの規格を統合したものである。

2016年現在の最新版は2005年3月に策定されたSAML v2.0である[4]

SAMLの標準では、認証属性権限の認可XMLアサーション(assertion, 直訳:表明)する方法と、これらの情報を伝送するためのプロトコルとに関する文法意味論を定義している[5]

概要編集

アサーション編集

アサーション(assertion, 直訳:表明)は、SAMLにおける最も基礎的な概念の一つで、これはユーザの認証情報、属性、ユーザへの権限の認可といったセキュリティ情報をXML文法で記載したものである[5][6]。複数のエンティティの間でアサーションをやり取りする事で前述したシングルサインオンID連携を実現する。

SAMLの標準はアサーションの詳細と、アサーションを伝送するためのプロトコルとに関する文法意味論を定義している[5]

アサーションはサブジェクト(subject)に対するステートメント(statements)という形式でセキュリティ情報を記述できる[6]

ここでサブジェクトは何らかの「セキュリティ領域」(security domain)にいるエンティティで、アサートされる対象である[7]。サブジェクトは人間であっても会社やコンピューターなどでもよい[7]

ステートメントには以下の三種類がある:

  • 認証ステートメント(Authentication statements): ユーザを認証したエンティティが作るステートメントで、例えば認証時刻や認証が行われた場所などの情報を含む[6]
  • 属性ステートメント(Attribute statements): サブジェクトの属性に関するステートメント[6]。例えばサブジェクトの名前、年齢、性別、ゴールドカードの保持者[6]である等。
  • 認可決定ステートメント(Authorization decision statements):サブジェクトに何らかの権限を与えた事を表すステートメント[6]。例えば特定のファイルへのアクセス権限や、特定の品物を買う事ができる権限[6]など。

パーティとロール編集

SAMLのユースケースでは最低限以下の2つのパーティが関わる:アサーションを発行するSAMLアサーションパーティ(SAML asserting party、直訳:SAML表明当事者)と、アサーションを受信してそれを用いるSAMLリライングパーティ(SAML relying party、直訳:SAML依拠当事者)という[7]。SAMLアサーションパーティはSAMLオーソリティ(SAML authority、直訳:SAML権限者)ともいう[7]

多くのユースケースではさらにユーザが関わる。このユーザ自身がSAMLアサーションパーティであることもある。

上述の2つのパーティやユーザ、もしくはそれ以外のパーティがアサーションの送信を他のパーティに要求するとき、その要求するパーティをSAMLリクエスター(SAML requester、直訳:SAML要求者)といい、それに応じてアサーションを送信するパーティをSAMLレスポンダー(SAML responder、直訳:SAML応答者)という[7]

SAMLの関係者は様々なロール(役割)を担う。例えばシングルサインオンにSAMLを使う場合にはアイデンティティプロバイダというロールとサービスプロバイダーというロールがある[7]

シングルサインオンでの利用編集

シングルサインオンは、ユーザが一度認証を受けるだけで複数のサービスやアプリケーションを利用できるようになる仕組みのことである。

SAMLをシングルサインオンで用いるには、ユーザが最初に認証を受けるサイトがアイデンティティプロバイダ(identity provider、 IdP)というロールを担う[8]。そのサイトでのユーザの認証情報やログインセッションのようなセキュリティ情報をセキュリティコンテクスト(security context)と呼ぶ[8]

一方、IdPにおけるユーザの認証情報を信頼してサービスやアプリケーションを提供するサイトはサービスプロバイダー(service provider、SP)というロールを担う[8]

IdPとSPは事前に両者で用いるユーザIDを対応付けることで、IdPのどのユーザがSPのどのユーザと対応しているかを明らかにしておく(すなわちID連携しておく)必要がある[8]

ユーザがIdPで認証を受けたあと、SPのサービスを利用しようとすると、IdPはユーザのセキュリティ・コンテクストからアサーションを作成し、アサーションをSPに送る[8]

アサーションには例えばユーザに関する以下の情報が載っている[8]

  • IdPとSPのユーザリストに載っている
  • IdPとの認証で受理された
  • SPが必要とするユーザの属性(年齢、性別、ゴールドカードのメンバーである等)

上で説明したユースケースではユーザはSPにアクセスする前にIdPに認証を受けるフロー(IdP-initiated flow)を説明したが、逆にSPにアクセスした後にIdPから認証を受けるフロー(SP-initiated flow)のほうがより一般的である。というのも検索サイトやブックマークなどから直接SPのサイトにアクセスした場合は、IdPからの認証を受ける前にユーザがSPにアクセスする事になるからである。このためSAMLは両方のフローに対応している[8]

ID連携での利用編集

saml-tech-overview 3.3 Identity Federation Use Caseを参照。


関連項目編集

外部リンク・参考文献編集

出典編集

  1. ^ What is SAML? - A Word Definition From the Webopedia Computer Dictionary”. Webopedia.com. 2013年9月21日閲覧。
  2. ^ saml-tech-overview 2.1 Drivers of SAML Adoption
  3. ^ IT用語辞典e-words SAML 【 Security Assertion Markup Language 】 2016年8月10日閲覧
  4. ^ OASIS Standards 2016年8月10日閲覧
  5. ^ a b c saml-core-2.0-os Abstract
  6. ^ a b c d e f g saml-tech-overview 4.3 SAML Components
  7. ^ a b c d e f saml-tech-overview 3.1 SAML Participants
  8. ^ a b c d e f g saml-tech-overview 3.2 Web Single Sign-On Use Case