ナレッジセンター
匠コラム

便利なSaaSをもっと安全に使うには？(番外編：SAML解説)

匠コラム: クラウド; セキュリティ; 認証

2019.03.06

ビジネス推進本部
第1応用技術部第1チーム
宮下徹

はじめに

前回までの連載(Part 1 ～ Part 3)の番外編として、今回はSAMLについてお話をします。前回まではBoxとVMwareWorkspace ONE UEMを組み合わせることでパスワードを入力せずに、「簡単に、かつ、セキュアにログイン」できるところをご紹介いたしました。

今回のコラムのテーマであるSAMLは、この「簡単に、かつ、セキュアにログイン」の実態であるシングルサインオンで使われているプロトコルです。本連載で紹介している設定を行おうとすると、実際にはSAMLを使ってBoxとWorkspace ONEを連携させる必要があります。

連載インデックス
便利なSaaSをもっと安全に使うには？(Part 1) 便利なSaaSをもっと安全に使うには？(Part 2) 便利なSaaSをもっと安全に使うには？(Part 3)

SAMLとは

それでは、SAMLとはどのようなものなのか。まずは基本的な情報からお話します。

SAMLはSecurity Assertion Markup Languageの頭文字を取ったものです。XMLをベースにしたプロトコルで、認証と認可の両方をカバーしています。なお、SAMLはサムエルと読みます (英語での解説ページには、「pronounced sam-el」と記載がありました)。ただ、サムルと読む人もいらっしゃると思いますし、実際にはサムエルでもサムルでも、どちらでも通じると思っています。

SAMLの主な使用用途は、本コラムでも紹介しているとおりWebブラウザを利用したシングルサインオンです (本コラムの連載では、Boxにログインするところだけを紹介していますが、本来は一度ログインすれば、Boxの他にもSalesforceやG Suite、Office 365といった別のサービスにもログインできるようになります)。

SAMLの歴史はそれほど深くなく、最初のバージョンがでてきたのは2001年のことです。その後、2005年に2.0が登場し現在主に利用されているバージョンとなっています。

標準化はOASIS (Organization for the Advancement of Structured Information Standards)という団体が行っています。オフィシャルな技術文書は下記URLに公開されています。
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

図１：SAMLでのSSO全体概要図

SAMLプロトコルの詳細

SAMLアサーション
アサーション(Assertions)とは、SAMLの重要な概念のひとつで、XMLでフォーマットされたメッセージとして、ユーザーの認証情報、属性、ユーザーの権限の認可といったものが記述されています。アサーションはサブジェクト(Subject)に対するステートメント(Statements)という形式でセキュリティ情報を記述できます。サブジェクトとはセキュリティ上なにかしらの領域になるもの(エンティティ)で、例えばコンピューターやユーザーといったものが挙げられます。また後述するIdP、SPもサブジェクトになります。

一方、SAMLにはパーティー(Party)という概念があります。SAMLを使う際には3つの定義されたパーティーを用います。

1つめはクライアントもしくはユーザーです。実際にはWebブラウザであることが多いです。
2つめはIdP(Identity Provider)です。こちらは信頼されたエンティティとして扱われ、ユーザーを認証し、SAMLを発行するパーティー(Assertion Party)として参照されます。本コラムの中ではVMware Workspace ONE がこちらに該当します。
3つめはSP(Service Provider)です。具体的にはユーザーがアクセスしたいアプリケーションやリソースを指します。こちらはSAMLを受信するパーティー(Assertion relying party)として参照されます。本コラムの中ではBoxがこちらに該当します。

SAMLはパーティーを信頼しあうことで実現されます。この信頼したエンティティ(主にIdP)によって作成されたクレームが、ユーザー自身と、そしてユーザーのロール(役割)や属性を検証して、受理されます。

やや複雑なのですが、上記のクレームがSAMLアサーションとして参照されます。アサーションはXMLフォーマットされたメッセージとして以下のステートメントを含んでいます。

認証アサーション：アサーションサブジェクトが認証された時刻や場所といった情報
属性アサーション：アサーションサブジェクトが紐づいている属性(例えばサブジェクトの名前、年齢など)
認可決定アサーション：アサーションサブジェクトが特定のリソースにアクセスできることをリクエストしたもの(例えばファイルへのアクセス権限など)

SPはIdPを信頼しますが、この信頼はIdPとSPの双方に共通の証明書によって確立されます。IdPの証明書を持つことで、SPは正しい証明書を使って署名されたSAMLアサーションかどうかを検証することができます。

IdPに認証されたユーザーがSPに対してアクセスをリクエストすると、IdPはSPにアクセスするためのSAMLアサーションを生成します。SPはそのメッセージを読み、そこからリクエストされているステートメント(認証された時刻の情報、ユーザーの属性、アクセスできるファイルなどの情報)を取り出します。
※図2をご参照ください

図2. SAML パーティー

SAMLの認証方式

SAMLの認証方式には大きく2つの方式があります。

IdP-initiated
SP-inisitated

IdP-initiated
IdP-initiated メソッドはユーザーが最初にIdPに接続する方式です。認証されたユーザーはSPへのアクセスを要求します。IdPはSAMLアサーションを生成し、ユーザーのWebブラウザに渡し、ユーザーをSPにリダイレクトします。この方法のSAMLアサーションはSPに渡され、セッションを確立します。

図3. IdP-initiated

ユーザーがIdPにアクセスしログインを試みます
IdPはパスワードを要求したり、証明書を要求するなどして認証します(Authenticate Challenge)
ユーザーが正しいパスワードを入力するなどして認証されます
SPに対するサービスを要求します
IdPはSAMLアサーションを生成し、ユーザーに渡します
ユーザーはSAMLアサーションをSPに渡します。SPはSAMLアサーションを検証しアプリケーションへのアクセスを許可します
セッションが確立されます

SP-initiated
IdP-initiatedと比較して、SP-initiatedの大きな違いは、ユーザーが最初にSPにアクセスすることです。SPではどのIdPがユーザーを認証できるかが予め定義されています。ユーザーのWebブラウザは定義づけられたIdPにリダイレクトされます。認証されると、ユーザーはIdPから受け取ったSAMLアサーションをSPに送信して、セッションが確立されます。

図4. SP-initiated

ユーザーがSPにアクセス要求します
SPはIdPにセッションをリダイレクトします
IdPからAuthenticate Challengeが来ます
SPに対するサービスを要求します
IdPはSAMLアサーションを生成し、ユーザーに渡します
ユーザーはSAMLアサーションをSPに渡します
セッションが確立されます

SAML Bindings

SAML を要求するパーティーをSAMLリクエスター、SAMLを受け取る側をSAMLレスポンダーといいます。SAMLメッセージをリクエスターとレスポンダーで交換する際にどのようなメカニズムで行うかを定義づけたものをSAML Bindingsと呼びます。

SAML 2.0のBindngsには以下の種類があります。

SAML SOAP binding (based on SOAP 1.1)
Reverse SOAP (PAOS) binding
HTTP Redirect Binding
HTTP POST Binding
HTTP Artifact Binding
SAML URI Binding

代表的なものは太字になっているHTTP Redirect Binding、HTTP POST Binding、HTTP Artifact Bindingです。

HTTP Redirect Binding
SAMLプロトコルのメッセージをHTTP GET リクエストのURLクエリ文字列として直接渡す方法です。URLの文字列は長さに制限があるため、HTTP Redirect bindingは短いメッセージの場合に適しています。例えば以下の＜samlp:AuthnRequest＞メッセージのような場合です。

https://idp.example.com/SAML2/SSO/Redirect? SAMLRequest=fZDBTsMwEER/JfI9qUNToKskUtRyiAQEUYgENxOtaJCzDt61KH+PaS/lwn3ePM2UbCY7QxNkT4/4GZAl6dHz6KhSF5lWSbut1C7Y8bIf+g11V/vu/eXZF+mq+7jxSxMDzAFbYjEkkdH5OtXLVK+edAFFDnmera/1q0oOkyWGo69SwRM4wyMDmQkZZIBdc3cLUQmzd+IGZ1Vd/qbhKPBn/P+4YUYvcYCq39whI5RycdZzKp3hPoLt9sHZcfhOGmvd18ajEayU+IBqUZ+ov9/UPw==

HTTP POST Binding
より長いメッセージ(例えば、署名付きのSAMLアサーション)は、HTTP POST Bindingのような別の手段で送信する必要があります。もともとPOST Bindingsはデジタル署名の利用を前提に作られました。ユーザー（実際にはWebブラウザ）はIdPに対して認証要求をHTTPのPOSTで問い合わせます。IdPはアサーションにデジタル署名をしてユーザーに渡します。SPはこの署名を検証し、正しいことが分かればユーザーに認可されたサイトへのアクセスを許可します。

Artifact
Artifactと呼ばれる特別なメソッドについてご説明します。ここではSP-initiated の Artifactについてご紹介します。前述したメソッドに似ている点として、IdPに認証のためのGETリクエストがリダイレクトされます。しかし認証されたユーザーはArtifactと呼ばれるSAMLメッセージを受け取ります。ArtifactはSPに渡されます。SPはArtifactに格納されている情報を用いて、IdPに対してArtifactが有効なものかどうかを直接検証します(ユーザーを介さない)。SPはArtifactリゾルブを生成しIdPに送ります。Artifactリゾルブを受け取ったIdPはSPが認証と認可が行えるようになるためのArtifactリスポンスを送り返します。

Artifactのメリットは、SAMLペイロードがユーザーからオフロードされることにあります。一方、デメリットは、SPとIdPの間でやり取りが発生してしまうことです。以前の携帯電話端末(いわゆるガラケー)のようにWebブラウザで扱えるデータサイズに限界があった際、SAMLアサーションそのものをブラウザ経由でPOSTする代わりに比較的サイズの小さいArtifactを用いてID連携する必要がありました。ただし、最近はスマートフォンになり端末側のブラウザに以前のような制限がなくなったこと、加えてSPとIdP間で直接通信をすると例えばクラウドと社内のIdP間を連携させる場合など通信の設定が煩雑になるといった別の問題が発生しやすいことから、最近はあまり使われることがなくなってきました。

図5. Artifactを用いたSP-initiated

ユーザーがアクセス要求を出します
ユーザーをIdPにリダイレクトします
ユーザーが認証されます
IdPはSAMLアサーションとSAML Artifactを生成し、Artifactのみユーザーに渡します
ユーザーはSAML ArtifactをSPに送ります
SPはArtifact ResolveをIdPに要求します
IdPはArtifact ResponseとしてSAMLアサーションを送信します
セッションが確立されます

SAML アサーションの中を見てみましょう

SAMLアサーションはSAML Tracerというアプリケーションを利用することで簡単に確認することができます。SAML TracerはFirefoxのアドオンもしくはChromeのエクステンションとして用意されていますので、インストールする際はWebブラウザに組み込むかたちになります。

Firefox版SAML Tracer
https://addons.mozilla.org/en-US/firefox/addon/saml-tracer//addons.mozilla.org/en-US/firefox/addon/saml-tracer/
Chrome版 SAML Tracer
https://chrome.google.com/webstore/detail/saml-tracer/mpdajninpobndbfcldcmbpnnbhibjmch?hl=en

SAML Tracerを用いることで、SAMLメッセージの中身やステートメントを読むことができます。中身を見てみると、SAMLメッセージには多くのものが含まれていることが分かります。例えばユーザー名、ユーザーの役割、グループ、Email、上司の名前、認証方法などです。SAMLメッセージには多くのものが含まれています。例えばユーザー名、ユーザーの役割、グループ、Email、上司の名前、認証方法などです。

図6. SAML Tracer

SAMLを使ってフェデレーションするために必要となる情報

SAMLを設定するには、IdPとSPの間でさまざまな情報を交換する必要があります。例えば、IdP側で必要となる情報としては、以下のようなものがあります。

IdPの証明書
・これはとても重要です
・SPがこの証明書をベースにしてIdPを信頼することができるようになります
Logout URL
・必須ではありません
・IdPからログアウトした際に表示するページの情報や、IdPのアプリケーションポータルがどこにあるのかといった情報です
IdPのメタデータ
・テキストベースのXMLファーマット化されたIdPメタデータをSPにアップロードする、もしくは、参照先のリンクを用いることで、SPは設定に必要な情報を得ることができます。メタデータを利用しない場合、手動で設定することもできます。

また、IdPに登録すべきSPの情報としてSAMLアサーションをPOSTするURLが挙げられます。このURLはSPがSAMLメッセージをListenしているURLとなっています。

さらに、IdPとSPの双方がユーザー定義の方法について同意する必要があります。ユーザーを定義するためにどの属性をSPに送信すればいいのかなどが定義されます。多くの場合メールアドレスが利用されますが、その他の値が利用されることもあります(ユーザーIDなど)。こちらに関しては後述するNameIDフォーマットで解説します。

フェデレーションするために必要な情報をまとめると以下のようになります。

IdPの情報

メタデータ(idp.xml)
IdPのSAML証明書
・SAMLアサーションのへのサインインと保護のために用いられる証明書です
・SPがSAMLアサーションを検証できるようにするため、IdPのSAML証明書を渡しておく必要があります
(Logout URL)
・必須ではありません

SPの情報

メタデータ(sp.xml)
SAML 証明書 (SP-initiated用)
SAMLがポストされるURL (Audience、アサーションコンシューマサービス、受け取る側の名前)

その他の情報

同意された属性とマッピング方法(もっとも重要なものはUser ID)
Bindingsのタイプ (HTTP リダイレクト、POST、Artifact)

NameID フォーマット

前述のとおり、IdPのアカウントとSPのアカウントをひもづける必要があります。SAMLでは、NameIDというユーザー識別子をIdPとSPで共有します。NameIDは以下のようなフォーマットで記述されています。

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Persistent identifiers
こちらのフォーマットの場合、IdPはSPの持っているローカルアカウントにひもづけるためにPersistent identifiersを提供します。各Persistent identifiersは特定のサービス用にユーザープロファイルを定義づけます。イメージとしては taroForAir、taroForCar、taroForHotel、といった具合です。SPの持つサービス内のローカルIDとリンクされるため、1つのプロファイルは1つの特定のサービスとひもづきます。

Transient identifiers
Transient identifiersはIdPからSPに対して発行され、SP上で許可されたセッション内のユーザーとして定義されますが、そのユーザーはSPが実際に要求したものではありません(つまり、仮名のユーザーです)。そのため、"匿名ユーザー(Anonymity、IdPはSPに実際のユーザー名を伝えない）"のアサーションにSP上のリソースに対するアクセス許可を持たせるといったことが可能です。この場合、SPはWebブラウザにアクセス許可を与えますが、匿名ユーザー(Anonymity)の本当のユーザー名を知りません。

Unspecified identifiers
Unspecified identifiersは、"要素の解釈は、個々の実行に任せている"ということを意味しています。IdP側で実際のフォーマットを定義し、SPがそのフォーマットされたデータの解析方法を知っているものとみなします。例えば、IdPが "UserName=XXXX Country=JP" といったデータフォーマットを提供した場合、SPはこのアサーションを受け取り、実際のUserName が"XXXX"であることを解析します。SPが特定のSAML Subject形式(UPNやEmailなど)を要求していない場合は基本的にこちらを選択します。

Workspace ONEでBoxのSAMLを設定した際の実際の画面は以下のようになります。
NameIDフォーマットのところは「未指定」となっており、値としては${user.email}となっていることがわかります。つまり、上記のUnspecified identifiersで定義していることになります。

図7. VMware Workspace ONE によるBoxのSSO設定

まとめ

いかがでしたでしょうか。SAMLはなかなかとっつきにくい概念かと思います。専門用語も日本語に訳しづらいですし、XMLをベースにしているため見た目も若干複雑です。
ただ、SAML Tracerなどで少しずつ読み解いていくと、どのような動きをしているかが分かってくるかと思います。

クラウドとモバイルが主流になりますとSAMLを始めとしたシングルサインオンの需要はますます高まってくると思います。本コラムを通じてみなさまの業務に少しでもお役に立てましたら幸いです。

最後にいつもの宣伝になりますが、BoxやVMware Workspace ONEにご興味がございましたら、ぜひ当社の営業までご連絡をお願いいたします。SBC(ソリューションブリーフィングセンター)といった最先端のソリューションをご覧いただける場をご用意してお待ち申し上げております。

Webからのお問い合わせはこちらから

お問い合わせ窓口へ

ナレッジセンターを検索する

電子カタログ