認証基盤の冗長化 技術編
学認CAMP 2013 ＠千葉大学,2013-09-11,
2013
09 11, 国立情報学研究所 西村 健

冗長化（クラスタリング）： システムを複数ノードで起動しておくを複数ド 起動おく↓ １つのノードが故障等で停止してもサービスを続けられる
１ のノ ドが故障等で停止してもサ ビスを続けられる→問題なく続けるためにはデータの同期が必要
IdP

障害

同期IdP

※特殊なケースを諦める（再度認証してもらう）のも重要
特殊なケを諦 る（再度認証も う） も 要
2 (A) Shibboleth IdP

以下を含めて StoredIDのためのDB uApprove.jpのためのDB
A
j のためのDB

 (B) LDAP or DBなど
3

いわゆるバ クエンド
いわゆるバックエンド ①振り分け

 ②固定


ユ ザ毎に特定のユーザ毎に特定のノードに固定するとか

 ③同期

4IdP

IdP5(A)IdP(B)LDAP①振り分け？

？

②固定？

？

③同期？

？

 既存技術でカバーされると思うのでばっさり省略（実際に運用している方から情報をいただければありがたい
実際 運る方から情報を ただ ればあ がたです）
 「(A)IdP」内のDBの冗長化についても既存技術で「(A)IdP 内のDBの冗長化についても既存技術で このあと紹介する各種技術とは独立

LDAP

IdP
IdP

LDAP

③同期
6

①振り分け

（②固定 は不要）

7(A)IdP(B)LDAP①振り分け？

OK

②固定？

OK

③同期？

OK

「①振り分け」について：
 ネットワークプロトコルレベルで解決
ネ トワ クプ ト ルレベルで解決
VRRP
 Anycast ロードバランサ「②固定」について：
 Active-Standby構成y ロードバランサを入れる
sticky機能でcookie情報等を元に特定のノードへの紐付けが可能 そもそもShibbolethはハードウェアロードバランサ+Terracotta推奨（情報が古いかも）

ただし，（ハードウェアのものは特に）高い！
8

 DNSラウンドロビン的ノードにDNSサーバを同居させ委任する
 ノードが生きていればノ ドが生きていればDNS的に応答できる

親DNSサーバ
idp.example.ac.jpについて委任（NSに設定）IN NS xxx.xxx.xxx.xxx
IN NS yyy.yyy.yyy.yyy

それぞれ自分のIPアドレスに名前解決する
IdP

IdP

xxx.xxx.xxx.xxx

yyy.yyy.yyy.yyy

 詳細はmeatwiki.nii.ac.jp GakuNinShare のDNSの委任(delegation)を用いたDSの広域分散 にて9 同一ブラウザが一度アクセスしたノードにアクセスするようにブラウザ①idp.example.ac.jp①idpexample ac jp
としてアクセス②リダイレクト先ホストを1.idp.example.ac.jp
として応答

IdP

IdP

1.idp.example.ac.jp

2.idp.example.ac.jp

 詳細はmeatwiki.nii.ac.jp GakuNinShare のIdPクラスタ向けセッション固定方式 - Sticky Login にて

10

11(A)IdP(B)LDAP

①振り分け

OKOK

②固定

OK

OK

③同期？

OK

 ユーザが認証済みという情報

ログイン後 長期間存在する（～8時間）
 ログイン処理中のみ存在する情報

ログイン画面を出して，ID/パスワードを送信するまでの間両者が別のノ ドだ たらどうなる？
 両者が別のノードだったらどうなる？
 短期間


12

 昔からの定番

Terracotta方式

 最近登場

Stateless Clustering方式
 repcached(memcached)方式
 （DB方式）…現在調査中
13

Tomcatの汎用的な冗長化ソフトウェア
特長： 完全な冗長化
全てのデータを（JavaのObject単位で）レプリケートする
 「②固定」を考えなくても良い

デメリット：デリット
 複雑
 相性問題（バ相性問題（バージョン間の差異が問題に）ジョン間の差異が問題に）
 Java SE 7は非サポート？
14

osuidpextプラグイン使用
 レプリケートすべきデータをcookieやID(transientID)に埋め込む！
 軽い！
 ノード間の通信がゼロ
ノ ド間の通信がゼ

同一ネットワークセグメントである必要がない

不完全な冗長化

短期間情報について「②固定」を考慮する必要
 IdP機能制約あり － 学認が規定する範囲では問題なし
 Single Log-Out(SLO)できないとかIDが想定外に長くなることによりSP側で誤動作の可能性


例: Web of Knowledge

15

SAML1でもフロントチャネルを使うことで回避(includeAttributeStatement="true")Memcached StorageServiceプラグイン使用
 レプリケートすべきデータをmemcachedに置く
プ ケ
すべきデ タをh d 置く

memcachedをDBとして用いる
 repcachedはmemcachedをレプリケート対応したもの
h dはh dをレプリケ ト対応したもの
 ある程度軽い cookie/IDなど、外部に対するデータ形式は変更しない
cookie/IDなど 外部に対するデ タ形式は変更しない

デメリット
デメリット：
 不完全な冗長化


短期間情報について「②固定」を考慮する必要 ノード間通信が少し

16MeanTestTime(ms)TPS（トランザクション/s）T
Terracottatt1235 991235.99

15 22
15.22

Stateless398.6147.20

repcached

494.4438.89

 あまり最適化してませんが…
 statelessはCryptoTransientID無効での計測
t t l
はCt T
i tID無効での計測
 詳細は後述のウェブページ参照
17

 2012年から冗長構成で運用中
 採用した技術

VRRP + Keepalived
 Stateless Clustering StoredIDやuApprove.jpはDBとしてMySQLを使用
 MySQLマルチマスター構成
 上記を2ノードで運用
 LDAPは別途Active Directoryのクラスタ構成
18※冗長構成のActive Directoryは除きます19 今選択するならstatelessかrepcachedか？
最も単純 － Stateless Clustering 機能的に制限あり

中間的 － repcachedh d 最も複雑 － Terracotta 将来的なサポートが不安
将来的なサポ トが不安

※バックエンドの冗長化も忘れずに

20

Shibboleth-IdP冗長化環境構築手順書（Stateless Clustering編）
 Shibboleth
Shibboleth-IdP冗長化環境構築手順書（memcached編）
IdP冗長化環境構築手順書（memcached編）


repcachedは最後にちょこっと

Shibboleth-IdP冗長化環境構築手順書（Terracotta編）
金沢大学提供学認Webサイト > 技術ガイド > IdPカスタマイズ の「ロードバランサー配下のシボレスIdP環境設定に関する検証実験」の項も参照のこと．

Shibboleth-IdP冗長化パフォーマンス比較試験報告書



IdPクラスタ向けセッション固定方式 - Sticky LoginDNSの委任(d l
DNSの委任(delegation)を用いたDSの広域分散ti )を用いたDSの広域分散

いずれもmeatwiki.nii.ac.jpのGakuNinShare > 技術情報
以下にて公開しています．
21