学認のサービス連携推進のための機能開発
秋⼭ 豊和
京都産業⼤学内容• 背景と課題• 取り組んだ内容（１）– 拡張機能を用いた利便性・セキュリティの向上• 取り組んだ内容（２）– Shibboleth SPとアプリケーションフレームワークの親和性向上• 取り組んでいる内容– 新しい形式のサービスへの対応

• まとめ

背景
• WebアプリケーションとSSO– Webアプリケーションの増加– SSOによる認証統合• SSO化のメリット– パスワードの強化– 多要素認証の導入による認証強化• SSOで統合しておけば、導入コストは低減可• リスクベース認証の併用により利用コストも低減– ID統合管理– アプリケーション間のデータ連携– etc.

背景• 連携サービスの増加– SSOによる利点の拡大– 組織としてのサービス改善• 連携サービスの対象– 学内サービス– 学外サービス
学認によるメリットが⼤きい部分

SSOの課題(1) 「連携サイトの増加」に伴う利便性・セキュリティの課題(2) 「連携サービスの追加」に伴うアプリケーション開発の課題

ShibbolethのSSO手順
外部サービス学認フェデレーション

SP (Service Provider)

A Com. SP
C Lab. SP
B Univ. SP大学の認証サービス
IdP(Identity Provider) A 大学 IdP

A 社のサービス(4)
認証要求

B 大学 IdP

Xxxxx xxxxxxx.
http://xxx.xxxxxxxxxx.

(7) (1)

認証応答 (6)

C 大学 IdP

認証サービスUsername
Password(2)

DS (DiscoveryService)

(3)

(5)
A 大学

(5) 自組織の IdP
で認証(7) アクセス制限がかかったページを提供

ユーザ(A 大学)A 大学 IdP
B 大学 IdP
C 大学 IdP選択(3) 自組織のIdPを選択

（１）連携サイトの増加
連携サイトの増加により共通基盤の価値が向上
連携サイトの増加により下記ようなの懸念が増⼤
主にエンドユーザの課題
Embedded DS(1) 所属組織のIdP選択の手間の増加
・ユーザ教育コスト増加の懸念(2) ID・パスワードの資産価値の増大

問題B

問題A

(3) 組織外サービスの利用機会の増加
・フィッシングの懸念

必ずしも対策できていないブラウザ拡張機能を使って解決できないか？

7

問題A

フィッシング詐欺• フィッシング詐欺で盗まれるもの
偽 A 社 SP

A社
サービス
Xxxxx xxxxxxx.
http://xxx.xxxxxxxxxx.

本物

偽サイト
偽 A 大学 IdP

A 大学 IdP

A 社 SP

A 大学
認証サービス
A 大学
認証サービスUsername
Password

Username
Password

クレジットカード番号のような個⼈情報

ID とパスワード

攻撃（２）

攻撃（１）

A社
サービス
Xxxxx xxxxxxx.
http://xxx.xxxxxxxxxx.

フィッシング詐欺対策• URL Reputationサービス– 自動的に悪意のあるURIに対して警告を出してくれる– Internet Explorer： SmartScreen– Google Chrome： Safe Browsing API• Firefox, Safariも使用
Good!

ユーザの事前知識がなくても適切にフィッシングサイトを除外してくれる
しかし．．．
本当にフィルタ結果を信用できるのか？

学認を通じて信頼できるサイトの情報を得ているそれを利用できないか？

URL Reputationサービス
ソーシャルエンジニアリングを用いるマルウェア（socially engineered malware、以降SEMと略）に対する防御力

実はCAMPというマルウェア対策
ブラウザのシェアの仕組みで防御されている

www.nsslabs.com

www.nsslabs.com

フィッシング対策として取り組んだ内容• PKIを用いたアプローチ• チャレンジレスポンスを利用したアプローチ

PKI を用いたアプローチ• どうやって情報を保護するか？
学認は正しいSPのURIを知っている
偽 A 社 SP

A社
サービス
Xxxxx xxxxxxx.
エンドユーザは正しいSPの
http://xxx.xxxxxxxxxx.
URIを覚えられない

本物

偽物
偽 A 大学 IdP

A 大学 IdP

A 社 SP

A 大学
認証サービス
A 大学認証サービス

Username
Password

Username
Password

クレジットカード番号のような個⼈情報

認証にPKIを⽤いればIDとPassword
認証情報を保護できる

攻撃（２）

攻撃（１）

A社
サービス
Xxxxx xxxxxxx.
http://xxx.xxxxxxxxxx.

学認はどのようにしてメンバIdP，SPを記憶しているか？
• メタデータ(IdP/SP 証明書)の共有
ただしサーバ間のみ

1. IdP/SPの証明書を収集(SAMLメタデータ)
2. IdP/SPの証明書に信頼できる証明書で署名
3. IdP/SP証明書の配布

信頼できる証明書
（秘密鍵）
署名
IdP1
署名⽤
証明書

IdP1

IdP/SP は互いに識別可能
SAML認証要求・応答はIdP/SP証明書を検証に利用証明書配布サーバ

IdP2

IdP3

IdP2
署名⽤
証明書

SP1
署名⽤
証明書

SP1・・・

SP2

SP3

学認

証明書共有範囲の拡張エンドユーザまで• IdP/SPサーバ証明書をエンドユーザに共有
証明書および拡張機能配布⽤
サーバ(1) 署名信頼できる証明書（秘密鍵）

学認
IdP3 IdP2

SP3 SP2

IdP1

SP1

署名

ブラウザ
拡張機能

現状
Firefoxのみ(2) ダウンロード
拡張機能の配布ブラウザ
拡張機能

証明書共有範囲の拡張
エンドユーザまで• IdP/SPサーバ証明書をエンドユーザに共有
署名

(3)署名

証明書および拡張機能配布⽤
サーバ

信頼できる証明書（秘密鍵）

Provider List
IdP1
サーバ
証明書

学認
IdP3 IdP2

SP3 SP2

IdP1

SP1

SP1
サーバ ・・・
証明書(4) ダウンロード
学認
参加機関(5) 検証サービス提供者側とエンドユーザの相互認証を実現

IdP2
サーバ
証明書

学認
⾮参加機関

OKNO

ブラウザ
拡張機能

ユーザ認証にPKIを用いる場合の課題• 厳密なPKI は高い運用コストが要求される– 例）ICカード
Good!

• 簡易PKI はPKIの運用コストを低減できる– オンラインで公開鍵・秘密鍵のペアを配布– 秘密鍵はパスワードで暗号化
しかし．．．
サービスとユーザの相互認証を実現するには証明書共有範囲の拡張が必要
他にユーザ情報が登録されているIdPを認証する方法はないか？

チャレンジレスポンスを用いたアプローチ
ブラウザはチャレンジレスポンスを⽤いた
相互認証機能を持っていない(1) 署名信頼できる証明書
（秘密鍵）

ブラウザ
拡張機能
配布サーバ

ブラウザ拡張機能とIdPプラグインで実現

署名

SP

SP

IdP
IdP

IdP

ブラウザ
拡張機能

(2) ダウンロード

学認
SP

現状
Firefoxのみ

IdP サーバ
プラグイン

拡張機能の配布

Username

パスワードを⽤いた
IdP とエンドユーザの相互認証

Password

J‐PAKE

拡張機能

問題B

IdP選択の手間• IdP/SPの増加により発生
e.g. 出版社等– DSにおけるIdPリストが長くなる– 複数フェデレーションに対応したSPでは、IdP独自の選択画面をもつフェデレーションをまたがるDSがないため学認フェデレーション(日本)

複数フェデレーションをサポートするSPの例

X 社 SPUB 大学 IdPJB 大学 IdP

UC 大学 IdP

JC 大学 IdP
JA 大学 IdP

UA 大学 IdP
JA 大学
JB 大学
JC 大学

IdP 選択画⾯

InCommonフェデレーション(米国)

UA 大学
UB 大学
UC 大学

select

すべてのSPで統⼀されていない

問題B

IdP選択の手間• IdP/SPの増加により発生
e.g. Publisher– DSにおけるIdPリストが長くなる– 複数フェデレーションに対応したSPでは、IdP独自の選択画面をもつフェデレーションをまたがるDSがないため学認フェデレーション(日本)

複数フェデレーションをサポートするSPの例

IdP選択手順を簡易化
X Com. SP InCommonフェデレーション(米国)UB 大学 IdPJB 大学 IdP

UC 大学 IdP

JC 大学 IdP
JA 大学 IdP

UA 大学 IdP
default IdP

ブラウザ
拡張機能

JavaScriptを配布する
ことで選択⼿順を⾃動化

提案する構成
署名

ブラウザ
拡張機能

(2)
署名

信頼できる証明書（秘密鍵）

プロバイダリスト

IdP1
サーバ
証明書

署名⽤
サーバ

IdP2
サーバ
証明書

SP1
サーバ ・・・
証明書

プロバイダリストはIdP/SPの最新状況を反映 学認で収集された・証明書の知識を共有する
追加・更新・削除
フレームワーク・IdP選択⼿順の追加・更新・削除
理想的なオペレーション

プロバイダ
各組織のIdP/SP
登録⽤
運⽤担当者
サービス

(1)’
(1)
プライベートネットワーク(3) アップロード

サーバ
証明書

(1) サーバ証明書の収集

NAT

Federation
配布⽤
サーバ
インターネット
エンド
ユーザ

IdP2 IdP3
IdP1

SP2
SP1

SP3

プロトタイプ実装に関する考察• 提案フレームワークの課題– ブラウザ拡張機能の実装– ブラウザ拡張機能の配布• チャレンジレスポンスに対する攻撃– ブラウザ拡張機能に対するGUI攻撃• 標準技術への適合– プロバイダリストの配布フォーマット

Statistics of Desktop Browsers(Apr. 2013 – Apr. 2014)
Chrome 38%

IE 16%
Firefox 14%
Safari 7%

Market share estimates for desktop browsers
from: http://gs.statcounter.com/

Firefoxのシェアは徐々に減っている

Statistics of Mobile vs Desktop(Apr. 2013 – Apr. 2014)
Desktop 70%

Mobile 23%

Market share estimates for mobile vs desktop
from: http://gs.statcounter.com/

モバイルはもっと増えていくブラウザ拡張機能のサポート•Firefox– JavaScript, RDF, XUL– XPCOM (Nativeメソッドインタフェース)• nsIX509CertXX• nsISyncJPAKE•

Internet Explorer– Browser Helper Object (C#)– CryptAPI•

Chrome– JavaScript, HTML5, CSS– JavaScriptから利用できるのはブラウザAPIのみ– NativeインタフェースNSPIの利用は非推奨•

Safari– JavaScript, HTML5, CSS– JavaScriptから利用できるのはブラウザAPIのみ

基本的には JavaScript ,HTML5, CSSで実装
セキュリティライブラリのAPIはブラウザごとに異なっている
Web Cryptography API(W3C) の標準化により統一される可能性
Webアプリケーションにおける暗号演算のJavaScript API
David Dahl, Mozilla Corporation<ddahl@mozilla.com>
Ryan Sleevi, Google, Inc.
<sleevi@google.com>
http://www.w3.org/TR/WebCryptoAPI/

ブラウザ拡張機能の配布
課題運⽤による対策
配布サーバ

偽配布サーバ
偽ブラウザ
拡張機能
偽 ブラウザ
拡張機能
配布の危険性

A ⼤学

署名

運⽤担当者
署名の検証

エンド
ユーザ

ブラウザ
拡張機能

学認関連組織による間接的で限定的な配布
B ⼤学

Signature

運⽤担当者
署名の検証

エンド
ユーザ

コストに見合うかどうかが課題ブラウザ拡張機能

ブラウザ拡張機能へのGUI攻撃• 遠隔の悪意のあるWebアプリケーションが見た目の似たGUIを提供する可能性がある
本物 のGUIの例

OK

偽物 のGUIの例

OK

この部分が遠隔からダウンロードされたJavaScriptによって表⽰されている
もしすべてのユーザが同じインタフェースを使っていると簡単に攻撃できる対策として、インタフェースの見た目のランダム化機能や設定機能を提供

プロバイダリストの配布形式• プロバイダリストに含まれるもの– IdP/SPのentityIDとSAMLパラメータ– IdP/SPの証明書– 配布者の署名– 自動IdP選択コード

ほぼShibbolethのメタデータと同じ• メタデータフォーマット(XML)が利用可能– JavaScriptに良いXML処理系がない– JSONフォーマットを用いるのが簡単• プロトタイプ実装– JSON Simple Sign (Internet Draft) で実装– JSON Web Signature (Internet Draft) へのアップデートが必要か？

ひとまずまとめ• ブラウザ拡張機能を用いた学認の利便性・セキュリティの改善• 成果– 技術的な実現可能性についてはプロトタイプ実装
で示せた– 実用化には様々な課題が残る

（２）連携サービス追加• サーバ側アプリケーション実装のSP対応– 新たなWebアプリケーション開発環境の台頭– 新たな通信形式の登場

Webアプリケーション
フレームワークの利用状況
プログラミング言語の利用状況

高トラフィックサイトでの利用と多くのサイトでの利用

プログラミング言語の利用状況（CMS抜き）

まだ意外と少ない？

引用元： http://blog.websitesframeworks.com/

アプリケーションのSSO連携• PHPの場合
Webサーバ

環境変数でパラメータ受け渡し
mod_php

Apachemod_shibshibd

アプリケーションのSSO連携• Javaの場合
Webサーバ

AJPでパラメータ受け渡し

アプリケーションサーバ

mod_ajp
ApacheTomcatmod_shibshibd

アプリケーションのSSO連携• Rubyの場合（プロキシ型）
Webサーバ

ヘッダでパラメータ受け渡し
mod_proxy

Apachemod_shib

アプリケーションサーバ

Rails
on
Unicorn

shibd
偽装ヘッダを送信される問題

アプリケーションのSSO連携• Rubyの場合（モジュール型）Webサーバ

環境変数でパラメータ受け渡し
mod_passenger

Apachemod_shibshibd

アプリケーションサーバ

Rails
on
Passenger
Rails
on
Passenger

折角Railsのようなフレームワーク使っているのに毎回パラメータ受け取りコードを作りこむの嫌だなぁ．．．

アプリケーションのSSO連携• Rubyの場合（クラウド（例：Heroku））
Webサーバ（クラウド事業者管理）
mod_proxy
Apacheフロントエンドがいじれない（mod_shibが導入できない）

アプリケーションサーバ
（クラウドユーザ管理）
Rails
onUnicorn
ここにmod_shibがあるといいのにRuby‐opensamlのようなNative SAML実装が求められている

新たな通信形式の登場• ハイパフォーマンスブラウザネットワーキング– HTTP/2.0– WebSocket– WebRTC
Node.jsのようなサーバでのサービス提供

2014年５月発売

PersonaとShibbolethの連携• Persona– Mozillaプロジェクトが立ち上げたSSOのフレームワーク– BrowserIDというプロトコルを用いてSSOを実現– 一旦IdPで認証されると、その後はブラウザとSPが直接認証処理を行える• プライバシの確保（賛否両論）• P2Pのように接続先（検証者）が多い場合有効– Node.jsベースで認証サーバを実装• 調査結果– 連携ができることを確認– 想定していたユーザ・SP間のローカル認証機能は未実装– 現在残念ながらコミュニティプロジェクトに格下げ

WebRTCでの認証• SkyWay– NTTコミュニケーションズのブラウザ間リアルタイム通信フレームワーク– http://nttcom.github.io/skyway/– PeerJSを介してセッションを確立• ブラウザ間でP2P通信が可能– DTLS-SRTPにより端末間の相互認証・通信路暗号化を実現
P2PでもPeerJSを用いる場合は、PeerJSにpassport‐samlのようなSAML認証機能を追加すれば十分？

まとめ• 学認のサービス連携推進のための機能開発• 取り組んだ内容（１）– 拡張機能を用いた利便性・セキュリティの向上？

• 取り組んだ内容（２）– Shibboleth SPとアプリケーションフレームワークの親和性向上？

• 取り組んでいる内容– 新しい形式のサービスへの対応？