Comments
Description
Transcript
シングルサインオンにおける SAML と OpenID の連携接続手法の提案
2009 年度修士論文要旨 シングルサインオンにおける SAML と OpenID の連携接続手法の提案 A connection method for SAML and OpenID in Single Sign-On 電気電子情報通信工学専攻 08N5100042B 1. はじめに 福田 裕二郎 Yujiro FUKUDA る． この SSO を実現する方式として SAML や OpenID 等の仕様が存在するが，各仕様が並存し相互性が無い 近年，さまざまな Web アプリケーションが展開され という課題があった．本研究では，SAML と OpenID 利用する機会が増えてきている．利用者は使用する の相互接続を実現する手法の提案と実装に基づき，相 Web サービスが増えるたびに ID やパスワードの管理 互接続時の認証コンテキストの変換方式や，相互接続 が複雑になり，利用者の負担が増えてゆく．この利用 におけるセキュリティの課題および改善手法の提案， 者の負担を解決するために，シングルサインオン 考察を行う． （SSO）と呼ばれる，1 回の認証手続きで複数のサー 2. シングルサインオン ビスにログインできる仕組みが作られており，その SSO の仕様として SAML や OpenID 標準仕様が複数 サービス提供会社はホームページやブログ，電子メ 存在している状況である．本研究では SAML と ール，ポータルサービスなど複数のサービスを提供し OpenID という異なる仕様を用いたシステム同士での ているところも多く存在する． 相互接続を可能にする認証処理手法についての提案・ 考察を行う． 第１項でも示したが現行の認証の仕組みでは，ユー ザにとってはＩＤとパスワードの管理が煩雑になり， 通常，1 つのサービスにログインした後，他のサー サービス提供会社にとっては展開するサービス毎に認 ビスを使用する際には該当サービスにもログインしな 証を行うシステムの構築・保守等の運用コストが増大 ければならない．従来の認証方式ではサービス提供サ する．以上のような理由から，サービス毎にＩＤを発 イトごとにユーザデータを管理しており，ユーザはサ 行する仕組みはユーザとサービス提供会社の双方にと ービス提供サイトを利用するためにログイン要求を行 って不都合があると考えられる．このデメリットを解 うと，それぞれのサービスサイトごとに管理されてい 決する仕組みが SSO であり， これによって１つのＩＤ る認証サーバやアプリケーションにアクセスし，ユー の管理で SSO に対応しているサービス提供サイトの ザの照会を行った後，ユーザにログイン応答が戻って 全てのサービスの認証が可能になる．また，ユーザだ くる仕組みであった．このような状況下では，ユーザ けでなくサービス提供会社もサービス毎にＩＤやパス はサービスごとに個別の ID とパスワードを管理しな ワードを管理する必要はなくなる． ければならない．しかし，SSO を導入した環境下では SSO の実現には，共通ＩＤを含む認証情報の一元管 ユーザは 1 つの ID とパスワードによって複数のサー 理が必要で，状況によっては利用者の氏名や属性情報 ビスを利用することができるため，近年注目を集めて （住所やメールアドレスなど）等を一元管理する仕組 いる． みもまた必要になる．この仕組みには高い可用性（シ SSO の従来の認証方式と異なる点として，ユーザデ ステムをいつでも利用できること，壊れにくいこと） ータの管理を行う認証プロバイダがそれぞれのサービ が要求されると考えられる．何故なら，ログインを一 ス提供サイトごとに設けられておらず，ユーザは 1 つ 元管理するシステムに障害が発生すると，全てのユー の認証プロバイダの ID とパスワードを管理すること ザのログインが不可能になり，全てのサービスが利用 で複数のサービスを利用することが出来る仕組みであ できなくなってしまうためである． Web において SSO を実現させる場合，例えばエー SSO を実現できること，属性情報やアクセス情報伝達 ジェントモジュール方式の SSO 等， 一般的にはクッキ 等のセキュリティ情報交換の枠組みとして，通常のブ ーにセッションＩＤなどの情報を格納することで，認 ラウザ利用を想定していること，PKI（公開鍵暗号方 証された利用者に対するセッションを維持することが 式）のセキュリティ環境の利用のみを前提としてはい 可能である．但し，ブラウザがクッキーをサーバに送 ない（秘密鍵暗号方式による認証が行える）が PKI の 信するかはドメイン名で判断するため，クッキーはド 導入も可能であること，が挙げられる． メイン名の異なるサーバに送ることはできない．その SAML はアーキテクチャ（設計思想）と事業者間の ため，同一のサービス提供会社であっても複数ドメイ 合意に基づいて築かれる，サービスプロバイダとアイ ン間で横断的にサービスを提供する場合には利用でき デンティティプロバイダの関係を持ち，この関係を特 ない． にトラストサークル（Circle of Trust）と呼ぶ． SAML において，ユーザのアイデンティティ情報の ユーザ サービス提供サイト 認証プロバイダ ①ログイン要求 生成・管理や，ユーザの認証結果をトラストサークル 内の他のサービスプロバイダへ提供する役割を持つ認 ②認証要求 ③ID/PWD 入力 証プロバイダを IdP（Identity Provider）と呼び，ユ ーザにサービスや商品を提供する事業者のことを SP （Service Provider）と呼ぶ．SAML で Web SSO を ④認証応答 ⑤ログイン応答 実現する際に，SAML の仕様上 SP と IdP は事前に連 携を行わなければならない．これは SP と IdP が互い に信頼関係にあるといえる． 図 1 SSO シーケンス 属性交換にはアサーション（Assertion）と呼ばれる ユーザに関する証明情報や特定のリソースにアクセス 図 1 は一般的な WEB 上の SSO シーケンス図であ することの認可情報等を記載した XML 文書を送受信 る．まずユーザはサービス提供サイトへ①ログイン要 することで実現する． 求を行うと，サービス提供サイトは認証プロバイダへ 2.2 OpenID ②認証要求を行い，③で認証プロバイダの ID/パスワ 第 1 項に示したように，従来の認証はサービス提供 ード入力画面へリダイレクトが行われる．その後，認 サイト（ベンダー）がユーザ情報の管理を行うため， 証プロバイダが④の認証応答を行い，ユーザはサービ ベンダー主導の認証体系であった．それに対し ス提供サイトへリダイレクトされる．最後にサービス OpenID は，ユーザ自身が認証プロバイダの選択を行 提供サイトが認証応答の検証を行い，ユーザへ⑤ログ い，ユーザ情報の提供・変更の指示，あるいは履歴の イン応答が行われる． 以上が一般的な SSO のシーケン 管理といったユーザ情報の管理をユーザ自身が行える， スである． 即ちユーザ主導の認証体系である事が大きな特徴であ 第 1 項で述べたとおり， SSO には SAML や OpenID る．OpenID はアカウント ID に URL や XRI を使用 のような様々な仕様が存在する． 本項では各 SSO の仕 する．XRI とは標準化団体 OASIS により策定された 様と， 現在の SSO を取り巻く状況について詳しく説明 URI に対して上位互換性を持つ規格であり，URL を行っていく． （URI）は DNS（ドメインネームシステム）に問い合 2.1 SAML わせることでリソースの所在を得るという仕組みの記 SAML（Security Assertion Markup Language）は， 述方式である．一方，XRI は DNS ではなく XRI Proxy インターネット上で ID やパスワードなどのセキュリ Resolver というサービスで解決するプロトコルであ ティ情報をセキュアに交換するために標準化団体 る．解決とは，その XRI に対してどのようなサービス OASIS により標準仕様として策定された XML スキー が利用可能であるかを示す XML 文書（XRDS 文書） マおよびサービス間でのメッセージ交換方式である． の取得を行う事である． 特徴として，前項で示したクッキーを利用した仕組み OpenID において OpenID を発行する認証プロバイ とは異なり，プロバイダ間でクッキーを共有せずに ダを OP と呼び，サービスの提供を行うサイトを RP （Relaying Party）と呼ぶ．OpenID は通常，OP サ ーザが普段使用している OpenID だけでログインが可 イトのドメイン名とユーザが任意に指定する ID を組 能になるケースである．例えば普段 OpenID による み合わせた形のユーザ固有の URL になる．SAML は Web SSO を使用しているユーザが，SAML による サービス提供サイトと認証プロバイダであらかじめ結 SSO を実装しているポータルサイトへログインを行 んだ信頼関係がベースで成り立つセキュリティ性の高 いたい場合等が考えられる．一方の OpenID から い認証方式であったことを前項で示したが，OpenID SAML へ接続するのは SAML ユーザが普段使用して はそうした信頼関係が不要である． いる SAML の ID で OpenID サービスへのログインが 2.3 Kantara Initiative 可能であることを示したケースである． 本研究は 2008 年 6 月から Concordia Project のテー 特徴として SAML は OpenID よりもセキュリティ マの１つとして開始したものであるため，その関連と が高いと前項にて示した．この事から，ユーザが して Kantara Initiative について紹介を行う． OpenID よりも高いセキュリティレベルでの認証を行 2009 年まで Concordia Project と呼ばれる，アイデ う事を要求するようなケースが想定される．例えば普 ンティティプロトコルにおいて，相互運用性を設計す 段 SAML による Web SSO を行っているユーザが る世界的なイニシアチブプロジェクトが存在していた． OpenID によるログインを行っている blog サイトへ投 しかし，Concordia Project では技術標準として必要で 稿を行いたい場合などが考えられる． ある要件定義や，技術仕様策定等の取り組みは行われ 4. 接続方式提案 てこなかった．これらの課題の解決や ID 管理技術の 普及拡大等を目的として，Concordia Project，Liberty 第 3 項において示したユースケースによってユーザ Alliance 等の 7 つの団体が発起人団体となり，セキュ が抱える問題を解決できる事を示した．よってこのユ リティ確保，プライバシ確保といった観点からアイデ ースケースに基づいて接続方式の提案を行う．本項で ンティティ管理技術の高度化，相互運用，普及導入の はそれぞれのユーケースを実現するための構成，およ 促進を目指すために 2009 年 6 月に新たに設立された び実装結果を示す．認証方式として Yahoo!や mixi な 非営利団体が Kantara Initiative である．発起人団体 ど多数のユーザを抱えるサイトが OpenID に続々と対 である 1 つの Liberty Alliance はアイデンティティ管 応しつつあり，その認証方式を，外部サイトに OpenID 理技術に関する技術標準策定，セキュリティ評価，技 で公開している．さらに第 2 項で示したように 術標準に基づく実装の相互運用性試験等を実施する標 OpenID は公開されている OP サーバが容易に利用可 準化団体であり，Liberty Alliance の認証および SSO 能であるのに対して，SAML の IdP サーバはトラスト モデルの基盤となる技術が SAML である．([1]より一 サークル上の SP に対してしか認証が行えない．本研 部引用) 究では実装に際して相互接続の可能性を示すために実 3. ユースケース 際に運用されている外部の認証プロバイダを利用した 第 1 項において SSO 仕様が並立することでユーザ にどういった問題が生じるかを示した．そこで本項で 設計を試みた．そのため，SAML の IdP サーバによる 認証は困難であるので，本研究では SAML から OpenID のユースケースに基づいた設計を行った． は SAML と OpenID の相互接続が果されることで， ユーザの問題が解決されることを実際のユースケース サーバ 認証要求/応答 を挙げ具体的に示す．SAML と OpenID の相互接続を 想定したとき，最初に SAML のサービスサイトである SP から接続し，最終的に OpenID の認証局である OP から認証を受けるケースと，OpenID のサービスサイ SP RP+IdP モジュール 外部 OP トである RP から接続し，最終的に SAML の認証局で ある IdP から認証を受けるケースの二種類が存在する． 図 2 ソフトウェア構成 SAML から OpenID へ接続するのは OpenID を利 用しているユーザが SP を使用する際に，OpenID ユ 図 2 のソフトウェア構成を踏まえた上で，本研究で 行った接続実験の環境を表 1 にまとめた．サーバであ すメッセージに対し，付加情報として添付する． る Apache Tomcat 上に SP，IdP/RP，OP を設置し， 即ち 中継サーバがサービス提供サイトへレスポンス 各サーバを稼働させ， ユーザエージェントには Servlet を送信する際に，認証プロバイダが発行したメッセー の画面が表示されるようにした．なお，前提として OP， ジを添付して送信する方式を示した．さらに，それぞ IdP，SP にそれぞれ事前に ID とパスワードを発行さ れの提案方式についての問題点と改善案についての言 せ，さらに SAML の Trust List に IdP と SP それぞ 及も行った． れ追加しておいた． 表 1 実験環境 種別 ソフトウェア OS サーバ OpenID ライブラリ SAML ライブラリ プログラミング言語 Web アプリケーション フレームワーク WindowsXP Apache Tomcat6.0 openid4java 自作ソフトウェア Java Servlet/JSP 6. まとめ 本研究の主題である SAML と OpenID の相互接続 を，実際のサービスのシミュレーションを行い，ユー スケースを構築した上でそれぞれのシーケンスを整理 した．さらにそれを実装のための仕様とし，実装を行 い評価した．それにより両仕様の相互運用が可能であ ることが実装によって示すことできた． また，本研究で制作したゲートウェイはホワイトリ スト方式を採用しており，あらかじめゲートウェイ側 4.1 実験結果 初めに，制作した OP を用いることを前提に SP へ 接続したところ，問題なく OpenID を用いて SP にロ グインできることが確認され，ゲートウェイが稼働し たことを示せた． 表 2 接続した OP OP URL openid.ne.jp http://www.openid.ne.jp/ Mixi http://mixi.jp/openid.pl JugemKey http://jugemkey.jp/api/openid/ が接続する OP を定めている．本方式を採用すること でゲートウェイが安全性を認めた OP のみ接続を許可 し，DNS が汚染されていない等のセキュアな環境を前 提とした場合に信頼性の低い OP の接続を許可しない ことでフィッシング対策等に有効で，環境の条件つき ではあるが，SAML と OpenID の相互接続の安全性の 確保が可能であることを確認することができた． さらにより詳細な実装方式についての提案を行い， その提案に対しての考察を行った．これはまだ未実装 であるため，今後，この実装を行いさらに評価を行う 次に実際に一般公開されている表 2 の OP サイトへ ことで SAML と OpenID の相互接続における最適な OpenID を用いて接続を行い，有効性を確認した． 手法を見出せると考えられる． 5. 考察 参考文献 前項の実装は，両プロトコルの間で認証結果のみを 用いて相互接続を行うものであった．そのため詳細な 認証パラメータについては考慮しておらず，それを考 慮した手法を考えなければならない．そこで新たな接 続手法について提案を行った． 第一の方式である置換方式は SAML と OpenID の メッセージを比較し，各プロトコルに適する形に置き 換える，即ち認証プロバイダから伝えられたメッセー ジを，中継サーバがサービス提供サイトの要求する方 式に従ってパラメータを置換する方式である．第二の 方式である添付方式は，認証プロバイダが発行した パラメータを中継サーバが発行する認証結果を示 [1] 伊藤宏樹(2009) " アイデンティティ管理技術に関 する新団体「カンターラ・イニシアティブ」", NTT 技 術ジャーナル Vol.21 No.11 [2] OpenID Foundation, "OpenID Authentication 2.0 FINAL","http://openid.net/specs/openid-authenticati on-2_0.htm", 2007 年 12 月 [3] 畠山誠(2008)"SAML2.0 アイデンティティ連携技 術", 日本電気株式会社