シングルサインオンの歴史とSAMLへの道のり

©Copyright 2014 Mashmatrix, Inc. All rights reserved.
シングルサインオンの歴史と
SAMLへの道のり
Mashmatrix, Inc.
www.mashmatrix.com
!
Shinichi Tomita
stomita@mashmatrix.com

この資料は、株式会社ウフル (http://uhuru.co.jp/) の
社内セミナーにて使用した資料です。ウフル様のご好意
により、公開の許諾を得ましたので、公開いたします。
!

自己紹介
• 冨田慎一 Shinichi Tomita (@stomita)
• 株式会社マッシュマトリックス代表取締役社長
• Ex-salesforce.com
• Ex-OracleJapan
• 主業務：自社パッケージ製品の開発販売、クラウドサービスの
テクノロジーリサーチおよびコンサルティング
• デジタルアイデンティティ愛好家
• JavaScript エンジニア
• 調査対象テクノロジー領域：Node.js, Force.com, Heroku,
Sencha Ext JS などなど

本日の主題
シングルサインオン

シングルサインオン（SSO）
１度のユーザ認証で複数のシステムを利用可能にするシステ
ムあるいはその仕組みのこと

そもそも話
ユーザの認証って、どうやってるの？

基本中の基本： 
クライアント/サーバアーキテクチャ
サーバ
リクエスト
レスポンス
クライアント

ユーザエージェント
（ユーザエージェント）
サーバユーザ
リクエスト
レスポンス
クライアント
？

クレデンシャル  
(Credential/資格証明)
サーバユーザ
リクエスト
レスポンス
検証
クライアント
クレデンシャル 
（資格証明）
！

クレデンシャルの例
• パスワード
• 簡易・簡便ゆえに、ゴールデンスタンダードとして君臨。種々の問題の元凶にも
• 「本人しか知りえない知識を提示」できることで認証する
• クライアント証明書（ICカード内に保管）
• 「本人しか持っていない所有物を提示」できることで認証する
• セッションID
• 他の方式（パスワードなど）で認証を受けた後、資格証明の検証を簡略化するための工
夫
• セッションIDの値は他の人に知られてはいけない。簡単に推測できてはいけない
• セッションIDに紐付いているユーザが現在アクセスしているものとみなす

そもそも話：その２
シングルサインオンして 
何かメリットあるの？

ユーザ側のメリット
• 複数パスワードを覚えないで済む
• 単一パスワードの使い回しはご法度
• ログインする手間をかけることなく、複数のシステムをシー
ムレスに行き来できる
• 代理人となるサービスを利用して、作業を効率化できる

システム開発側のメリット
• 信頼できる強固なシステムに、ユーザの認証を任せること
ができる
• パスワードを安全にDBに保管していますか？ハッシュ化、ソルトなどについて知っ
ていますか？
• 攻撃者が用いる攻撃手法について、オンライン・オフラインの双方にわたって、
熟知していますか？
• パスワードでは不十分なとき、多要素認証のシステムを最初から作れますか？
すべてのアプリケーションに上記を求めるのは、酷である

よくある疑問
“認証機能を一箇所に集
めてしまって、もしそこ
のパスワードが漏れちゃっ
たら、だめなんじゃない
の？”
https://www.ﬂickr.com/photos/sylvain_masson/4195880838

逆に考える
• 守るべき点がただひとつに絞られる、と考える
• ほとんどのユーザはシステムごとに複数のパスワードを使いわ
けていない（共通パスワードを使いまわして利用）という現状
• すべてのサーバでユーザ認証機能をもつ 
最もセキュリティ的に弱いサーバに引きずられる（Weakest
Link）
• 中小企業の場合は、認証サーバにクラウドを活用す
るのも１つの策

サービス連携とSSO
サーバAユーザ
リクエスト
レスポンス
クライアント
サーバB サーバC
サーバD

サービス連携とSSO
サービスAユーザ
リクエスト
レスポンス
クライアント
サービスB サービスC
サービスD

サービスの時代 =「代理人」の時代
あなたの「代理人（エージェン
ト）」となるシステムが、あな
たの代わりにシステムに対して
作業を行う
https://www.ﬂickr.com/photos/thebaﬄed/6855905810

代理人にパスワードを渡す？
• アクセスされるシステムから見たら、どちらも「本人」に
見える
• 監査ができない
• 段階的な権限の委譲することが不可能 
（ALL or NOTHING）
代理人へは「認可」を渡すのが基本

「認証」と「認可」
• 認証（Authentication）と認可（Authorization）
• 認証：「あなたは〇〇さんですね」
• 認可：「あなたは△△してもいいですよ」
• ユーザには、どちらもシングルサインオンのエクスペリエ
ンスとして認識されることが多い

「認可」の形式いろいろ
• （署名なし）トークン形式
• 認可情報に紐付けられた割符のようなもの
• トークンを持っていればアクセス許可されている、とみなす
• アサーション形式
• 認可情報を文書として記述し、発行者の署名つきで渡す
• 電子署名されているので、認可情報は改ざんできない

UXからの分類
• ポータル型
• ポータルサービスへのログインで複数サービスの情報にアクセスする
• 実際にはポータルサーバへのログイン（認証）と、ポータルサーバが代理人と
なり各サービスへのアクセスするための許可（認可）が組み合わさっている
• 独立連携型
• それぞれのサービスが独立しユーザにサービスを提供するが、いずれ
かを認証サーバとして、ユーザのログインを統一している
• ディープリンクによる連携など 
（例：Google Apps Calendarをクリック Salesforce Contactへ追加）
• 一方から他方への代理アクセスを許す場合も多い

まとめ
• シングルサインオンとは、一度のユーザ認証で複数のシステムを利用
可能にするもの
• シングルサインオンのメリット
• ユーザが複数パスワードを管理しなくて済む
• アプリで認証システムを作らなくてもよい
• セキュリティ投資を一点に集中できる
• サービス連携の可能性が生まれる
• ユーザ認証は、ユーザの資格証明(Credential)を検証することで行う
• サービス連携が必要な場合は、代理人に対して「認可」をあたえる

シングルサインオンの歴史

クライアント・サーバの時代
• Kerberos（ケルベロス）
• MITにより開発された認証プロトコル
• 共通の仕組みを利用した認証プロトコ
ルを規定し、分散環境でのユーザ認証を
実現
• Active Directory環境におけるWindows
ログインには、Kerberosが用いられて
いる
• 最近Hadoop界隈でも使われてたりなど、
まだまだ現役
https://www.ﬂickr.com/photos/pheezy/58429180

WWW/ブラウザの時代
• サービスのすべてはWebで提供されるように
• ログイン Cookie発行
• Firewallの普及、HTTPポートのみが生き残る
• Cookieは単一ホスト（ドメイン）にのみ有
効
• シングルサインオンは、Cookieと密接に結びつい
たものに
• HTTP + Cookie上でシングルサインオンを実
現する必要性
https://www.ﬂickr.com/photos/johnkay/3182986643

.NET Passport
• マイクロソフトが提唱した、インターネットでのシングル
サインオンを実現するための仕組み
• 中央集権的
• シングルサインオンのみならず、課金サービスなどの提供
にも意欲的だったが、あまり普及せず

Liberty Alliance
• WWWの普及を踏まえ、インターネット規模でのシングルサイ
ンオン＋Webサービス連携を実現するプロトコルを定めるため
に生まれたプロジェクト
• Sun Microsystemsなどが中心となり、 
.NET Passportに対抗、分散型、非中央集権を目指す
• Circle of Trustの概念

SAML
• 「アサーション」を記述するためのXMLベースの仕様
• アサーションは認証・認可・属性の交換に利用できる
• メッセージ内容をXML-Signatureを利用して署名することによって実
現
• バージョン番号に注意
• 1.0時代はシングルサインオンのプロファイルとマークアップ、スキー
マ仕様
• そののちLiberty Allianceの成果（ID-FF）と合流し、シングルサイン
オンフローに加えメタデータなどを標準化、SAML2.0となる
• 現在はSAMLといえばほぼSAML2.0を指す

SAMLによる 
シングルサインオンの基本
• IdP=アイデンティティプロバイダ 
（認証サーバ）
• SP=サービスプロバイダ 
（連携するWebアプリケーション）

SAMLによる
シングルサインオン：基本フロー
ユーザエージェントユーザ
1. リクエスト
2. SAMLリクエストを付与して 
IdPへリダイレクト
SP
IdP

SAMLによる
ユーザエージェントユーザ SP
IdP
2.ユーザのログイン処理
3. SPへの連携に対するユーザへの
同意画面画面の提示

SAMLによる
ユーザエージェントユーザ SP
IdP
6. レスポンス
4. SAMLアサーションを付与して 
SPへリダイレクト
5. 検証

SAMLのなにがよかったの？
• シングルサインオンのプロトコルが標準仕様として策定され
た
• それまで：特定製品のプロプライエタリなプロトコルが主流
• 企業内ネットワークだけではなく、インターネットサービス
に利用できる
• ASP連携も重視後のクラウドサービスでの採用につながる
• メタデータの標準化
• 設定ファイルの交換だけで、シングルサインオンサーバとの接続
定義を設定可能

SAMLを使うには
• OpenAM
• アイデンティティ・アクセス管理のオープンソースソフトウェア
• Sun（現Oracle）が開発していたOpenSSOをForkしたうえで、
ForgeRock社が提供
• 事実上の標準に近い。多数のWebサービスが内部で採用している
• Salesforce Identity Connectもこちらを利用しているとのこと
http://forgerock.com/news-articles/forgerock-announces-new-oem-agreement-to-deliver-
salesforce-identity-connect/
• Microsoft Active Directory Federation Service

SAMLをサポートするクラウド
• Google Apps：SPの機能を提供
• Salesforce：IdP、SPの機能を提供
• Windows Azure Active Directory: IdP
• Microsoft Oﬃce 365: SPの機能を提供
• Amazon Web Services：SPの機能を提供。
• Amazon STSを経由してサービス連携も可能（S3, DynamoDBなど）
• Cybozu.com：SP
• PingOne : Ping Identity社。IdPの機能を提供
• OneLogin: OneLogin 社。IdPの機能を提供

まとめ
• クライアント／サーバ時代からシングルサインオンは必要と
されており、それを実現する技術としてKerberosがあった。
今でも広く利用されている。
• WWW時代には、HTTPでCookieを使ってユーザ認証する
のが主流となったため、ブラウザ＆HTTP上で利用できるシ
ングルサインオンプロトコルを提唱する企業が多く現れた
• Liberty Allianceは、Webで利用できるシングルサインオン
のプロトコルの標準化を実現し、SAML2.0の仕様へと結実
した

補遺：演習的なものへのリンク
• PingOneをIdPとして、SalesforceにSAMLでシングルサインオンできるように設定
する
• https://www.pingidentity.com/support/solutions/index.cfm/PingOne-Configuring-
Salesforce-com-to-use-the-Federated-ID-for-SSO
• Window Azure Active Direcotry をIdPとして、Salesforceにシングルサインオンで
きるように設定する
• http://msdn.microsoft.com/library/azure/dn308593.aspx
• SalesforceをIdPとして、Google Appsにシングルサインオンできるように設定する
• https://developer.salesforce.com/page/Configuring-SAML-SSO-to-GoogleApps
• SalesforceをIdPとしてAmazon AWS Consoleにシングルサインオンできるように
設定する
• https://developer.salesforce.com/page/Configuring-SAML-SSO-to-AWS

シングルサインオンの歴史とSAMLへの道のり

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à シングルサインオンの歴史とSAMLへの道のり

Similaire à シングルサインオンの歴史とSAMLへの道のり (20)

Plus de Shinichi Tomita

Plus de Shinichi Tomita (20)

シングルサインオンの歴史とSAMLへの道のり