熊本大学学術リポジトリ Kumamoto University Repository System

熊本大学学術リポジトリ
Kumamoto University Repository System
Title
統合認証基盤を用いたWebホスティングサービスの認証シ
ステム構築
Author(s)
針木, 剛; 赤坂, 浩一; 古村, 隆明; 永井, 靖浩
Citation
Issue date
2011-03-18
Type
Presentation
URL
http://hdl.handle.net/2298/23552
Right
統合認証基盤を用いた Web ホスティングサービスの認証システム構築
針木剛 1 、赤坂浩一 1 、古村隆明 2 、永井靖浩 2
京都大学情報環境部 1 、京都大学学術情報メディアセンター 2
1 はじめに
京都大学では平成 22 年度より統合認証基盤 (全学 ID、シングルサインオン、認証局、統合ディレクトリデータ
ベース、IC カード) を本格運用している。例えば、全学の教職員向け ID と学生向け ID を統合した全学 ID を格
納したディレクトリデータベース (統合 LDAP) を構築し、学内情報システムの認証等に活用している。また、シ
ングルサインオンの１つとして Shibboleth[1] システムを稼動させるとともに、全教職員に対して電子証明書を格
納した IC 身分証等を配付し、セキュアな Web サービスの多要素認証に利用している。
このような統合認証基盤を用いて、学内構成員向けの Web ホスティングサービスに対して以下の 3 点の改善を
実施し、よりセキュアな環境の提供と利用者の利便性向上が実現できたので報告する。
• ファイル更新時認証への活用
• Web シングルサインオンのための Shibboleth の導入
• IC カードによるログイン認証の導入
2 Web ホスティングの概要
Web ホスティングサービスは共用サーバ型と VPS 型のサービスを行っており、通常業務としてシステム運用管
理及び利用者対応がある。今回の改善は共用サーバ型のサービスを対象としており、このサービスでは、利用者は
コンテンツの運用管理だけで Web サイトの運用が可能である。
システムは以下のように運用している。
• OS は「Linux」、Web サーバは「Apache」[2]
• Apache の仮想ホスト機能により複数のホスト名の処理ができるため、複数の利用者が Web サーバを共用
• 仮想ホスト毎に UNIX 系システムのユーザ ID(以下システム ID とする) を割り当て、CGI のような動的コ
ンテンツの生成等機能は当該システム ID の権限において実行
3 ファイル更新時認証への活用
3.1 従来の課題
サイトの運用に関してそのコンテンツ管理を一人で行うと
認証
利用者A
サイト1の
システムID
いうことは希であり、例えば研究室なら教員と学生、学科・
専攻なら複数の職員で行う。従来、Web ホスティングサー
利用者B
ビスでは、システム ID を利用者アカウントとして利用者本
・
・
人への配布のみとしていたため下記のような課題があった。
• 複数利用者でのシステム ID とパスワードの使い回し
が発生し、更新した利用者がわからない。(図 1 参照)
権限
システム
利用者X
BからXは不正利用
図1
複数ユーザ利用での問題
• 管理するサイトが増えるとその度にシステム ID が配
認証
布され、ID やパスワードを管理する手間が増える。
権限
利用者A
サイト1の
システムID
(図 2 参照)
サイト2の
システムID
システム
・
・
サイトXの
システムID
図2
複数システム ID 利用での問題
3.2 統合認証基盤を用いた対策
これを FTP サーバ「ProFTPD」[3] の機
能を用いて、本人認証の機能とその認証した
認証
利用者A
AのID
利用者B
BのID
・
・
・
・
利用者X
XのID
権限
利用者をシステム ID と紐付けした権限割り
当ての機能 (認可及びアクセス許可) とに分
離した。本人認証には学内構成員全員に割り
当てられた全学 ID を格納した統合 LDAP
を利用した。
これにより下記のように改善できた。
抑制され、コンテンツ更新のトレーサ
システム
図 3 複数ユーザ利用での改善方法
1. 各利用者の全学 ID でログインしてい
るため ID とパスワードの使い回しが
サイト1の
システムID
認証
利用者A
権限
AのID
ビリティが可能になり、情報セキュリ
ティが大きく改善された。(図 3 参照)
権限を選択
2. 各利用者の ID は 1 つであるが、利用
者に設定された権限によって複数のサ
サイト2の
システムID
システム
・
・
サイトXの
システムID
イトが管理できるため複数 ID を管理
する手間がなくなり、利用者及びホス
サイト1の
システムID
図4
複数システム ID 利用での改善方法
ティング管理者の稼働が軽減された。(図 4 参照)
3.3 FTP サーバの設定と具体的なファイル更新フロー
リクエストの中でホスト名を指定できる http では仮想ホスト名毎に個別設定が可能だが、ftp ではポート番号や
IP アドレスでしか個別設定ができない。そのため今回の対策では、FTP サーバが複数のハイポートで待ち受ける
ように設定して各ポートに個別設定を施した。
具体的な設定は以下の通りである。(リスト 1 参照)
• 認可する全学 ID のリスト
• 紐付けしてファイルオーナとなるシステム ID
• 書き込む先のホームディレクトリ (Web 公開用のディレクトリを含む)
設定した後、利用者は以下のフローでファイル更新を行う。
1. 利用者はまず統合認証基盤の LDAP サーバに接続し、本人認証を行う。
2. 本人認証後、ポート番号に設定された認可情報にマッチした全学 ID だけが選別される。
3. 認可処理後、ポート番号に設定されたシステム ID をアサインしその権限でファイル更新を行う。また、当
該システム ID のホームディレクトリがトップディレクトリとなっている。
リスト 1 FTP サーバの設定
Def aultAd dress 192.0.2.1
Port 0
DefaultRoot ~
...
< Global >
TLSEngine on
TLSProtocol SSLv3
TLSRequired on
AuthOrder mod_auth_file . c mod_ldap . c
AuthUserFile / path / to / passwd
AuthGroupFile / path / to / group
LDAPServer ldap . example . kyoto - u . ac . jp :636
LDAPUseSSL on
LDAPAuthBinds on
LDAPDNInfo " BindDN " " password "
LDAPDoAuth on " base " " ( uid =% v ) "
L D A P D o U I D L o o kups off
L D A P D o G I D L o o kups off
L D A P F o r c e D e f a u l tU I D on
L D A P F o r c e D e f a u l tG I D on
L D A P G e n e r a t e H o m ed i r on
L D A P G e n e r a t e H o m e d i r P r e f i x N o U s e r n a m e on
...
</ Global >
< VirtualHost 192.0.2.1 >
Port 59000
LDA PDefau ltUID 59000
LDA PDefau ltGID 59000
L D A P G e n e r a t e H o m e d i r P r e f i x / home /59000
< Limit All >
Order deny , allow
DenyUser All
AllowUser OR 全 学 ID1 全 学 ID2 ...
</ Limit >
</ VirtualHost >
# アドレス
# デフォルトのポートはなし
# トップディレクトリはホーム
# フ ァ イ ル 認 証 と LDAP認証
# ファイル認証用ファイル
#
#
#
#
#
#
LDAPサーバ
SSLを使う
Bindする
BindするDNとパスワード
認 証 の 入 力 IDをDNに
LDAPからはシステムIDの情報を取得しない
# LDAPからはホームの情報を取得しない
# ポ ー ト ご と の VirtualHost設定
# ポ ー ト 番 号( ハ イ ポ ー ト)
# ア サ イ ン す る シ ス テ ム ID
# ホームディレクトリ
# 認 可 す る 全 学 IDリスト
3.4 利用者からのコメントと対応
今回の新しいファイル更新方法を運用するにあたり利用者からのコメントとそれらの対応について記述する。
• 同一の仮想ホストの中に複数の研究室や部署をディレクトリに分けてコンテンツ管理しても、他研究室や他
部署のディレクトリのコンテンツに対して書き込み制限ができないため、複数の組織のコンテンツの運用に
は向かない。
⇒ 単一組織でサービスを利用するか、それが難しい場合は適宜バックアップにて対応を推奨
• コンテンツ作成業者にファイル更新を依頼したいが、学内構成員のみの全学 ID を格納した統合 LDAP に
は業者の ID が存在しない。
⇒ 「ProFTPD」は認証に統合 LDAP を利用した認証に加えて、ローカルホストのファイル認証の併用が
可能なので、業者用アカウントをファイル上に作成して対応可能
• 従来は SCP や SFTP でファイル更新をお願いしていたが、新しいファイル更新方法では暗号化した SSL
上の FTP を利用する。一部のコンテンツ作成ソフトがこのプロトコルに非対応で、サーバ同期機能を利用
することができない。
⇒ まず自分の PC 端末内に保存してから当該プロトコルに対応したソフトウェアで更新が可能
4 Web シングルサインオンのための Shibboleth 導入
4.1 サービス導入の経緯
従来 Web コンテンツの閲覧制限や動的コンテンツによるコンテンツマネジメントシステムでは認証や認可をそ
れぞれ利用者側で準備してきたが、統合認証基盤の整備に伴い、これを利用したいといった要望が増えてきた。そ
こで Web ログイン環境としてシングルサインオンシステム (Shibboleth) を Web ホスティングサービスに導入
した。
4.2 Shibboleth とは
シングルサインオンは、複数の Web システムを利用する際、一度ログイン操作しておくと、他のシステムでは
ログイン操作をすることなくシステムを利用できるようにする仕組みである。Shibboleth は SAML2.0 に準拠し
た Federation システムで、統合認証基盤の一つとして平成 21 年度より運用している。なお、Shibboleth 認証に
は統合 LDAP を利用している。Shibboleth は国立情報学研究所で大学間連携のために利用されており、京都大学
も含め多くの大学で導入・運用の実績がある。
4.3 Shibboleth の動作
Shibboleth は電子的なコンテンツ等リソースを提供するシステム (Service Provider、SP) と認証・認可の判定
及び属性情報を提供するシステム (Identity Provider、IdP) が独立しており、SP と IdP の組織 (ドメイン) が違っ
てもシングルサインオンが可能である。
認証のフローを図 5 に示す。
(1) クライアントのブラウザから SP1 に Web アクセス
(2) SP1 が IdP へリダイレクトするよう指示
SP1
(3) クライアントは IdP にアクセス
(4) IdP の認証済み「cookie」があればそのまま SP1 へリ
ダイレクトを指示、なければ IdP 認証画面で認証後
「cookie」をセットして SP1 へリダイレクトを指示
SP2
・・
SPX
(2)
(5)
(1)
ブラウザ
(5) SP1 に IdP から受けとった属性情報を POST する。ま
た、SP1 の認証済みという「cookie」がセットされるの
(3)
IdP
(4)
図 5 Shibboleth の動作
で以降はログイン状態で継続的にアクセス
このように、一度 IdP で認証すれば、例えば次に SP2 にアクセスした場合、(4) の認証画面での入力が不要になる
ため、利用者は意識せずにシングルサインオン状態となる。
また SP が受けとった属性情報は Web サーバの認可設定に利用できるだけでなく、CGI などの動的コンテンツ
では Web サーバの環境変数の値として得られるので、コンテンツ管理システムなどで属性に対し閲覧者や編集者
のような権限を自動で割り当てることも可能となる。
なお通常は IdP へリダイレクトする (2) の前に DS(Discovery Service) により複数の IdP から当該 IdP を選択
する場合があるが、京都大学では運用していないため本稿では割愛する。
4.4 仮想ホスト環境での利用方法
Shibboleth の SP は共用型の Web ホスティングサーバ内で動作させている。この際、複数の仮想ホスト名に対
応させるには各ホスト名に対し「ApplicationID」を設定し、さらに Shibboleth SP ではデフォルトの設定に加え、
「ApplicationID」毎に下記情報の上書きが可能である。(リスト 2 参照)
• 仮想ホスト名のサーバ証明書とその秘密鍵
• 取得する属性情報に関する設定 (環境変数名など)
• IdP に関する設定 (サーバ証明書、URL など)
リスト 2 ApplicationID を上書きする設定
<! - - A p p l i c a t i o n I D の 設 定 -->
< RequestMap applicationId = " default " >
< Host name = " www . example . kyoto - u . ac . jp " authType = " shibboleth "
requir eSession = " true " / >
< Host name = " www1 . example . kyoto - u . ac . jp " applicationId = " vhost1 "
authType = " shibboleth " requireSession = " true " / >
</ RequestMap >
...
< A p p l i c a t i o n D e f a u l t s id = " default " policyId = " default "
entityID = " https :// www . example . kyoto - u . ac . jp / shibboleth - sp " ... >
<! - - デ フ ォ ル ト の A p p l i c a t i o n I D の 設 定 -->
< C r e d e n t ia l Re s ol v er type = " File "
key = " / etc / pki / tls / private / www . example . kyoto - u . ac . jp . key "
certificate = " / etc / pki / tls / certs / www . example . kyoto - u . ac . jp . cer " / >
< Sessions ... / > <! - - I d P へ の 接 続 方 法 -->
< M e t a d a t aProvider type = " XML " file = " idp - metadata . xml " / >
< A t t r i b u te E xt r ac t or type = " XML " file = " attribute - map . xml " / >
<! - - A p p l i c a t i o n I D の 上 書 き 設 定 -->
< A p p l i c a t i o n O v er r i d e id = " vhost1 "
entityID = " https :// www1 . example . kyoto - u . ac . jp / shibboleth - sp " >
< C r e d en t ia l Re s ol v er type = " File "
key = " / etc / pki / tls / private / www1 . example . kyoto - u . ac . jp . key "
certificate = " / etc / pki / tls / certs / www1 . example . kyoto - u . ac . jp . cer " / >
< Sessions ... / >
< M e t adataProvid er type = " XML " file = " idp - m e t a d a t a _ f o r _ v h o s t 1 . xml " / >
< A t t r ib u te E xt r ac t or type = " XML " file = " attribute - map_ for_vh ost1 . xml " / >
</ ApplicationOverride >
</ ApplicationDefaults >
SP での各種設定後、利用者は Web 公開用のディレクトリの「.htaccess」ファイルの設定だけで利用可能となる。
4.5 利用者からのコメントと対応
Web ホスティングサービス上で Shibboleth サービスの実運用を始めてから日が浅くまだ利用者も少数である
が、新しい技術であるため技術的な質問や運用方法に関する質問が多い。特に SP で Web アプリケーションを利
用する場合、そのアプリケーションでの設定方法もアドバイスする必要があるため、利用者と同じテスト環境を
サービス運用側でも準備して対応している。
5 IC カードによるログイン認証の導入
5.1 サービス導入の狙い
全教職員に配布した IC カードに含まれる電子証明書を利用して、ID とパスワードに比べてよりセキュリティの
高い Web ログイン環境を利用者に提供できる。具体的には、社会的影響の大きな学内 Web コンテンツに対する
制限に適用することを想定している。
5.2 IC カードログイン認証方法
本サービスは Web サーバの SSL によるクライアント認証を利用する。
京都大学の IC カードの電子証明書は学内でプライベート CA を構築し、そこで発行している。従って通常の
Web サーバにバンドルされているパブリック CA の証明書リストに、大学のルート証明書も追加して設定する必
要がある。あとは利用者が Web 公開用のディレクトリの「.htaccess」ファイルに SSL クライアント認証する設定
をするだけで利用可能となる。(リスト 3 参照)
ブラウザから IC カードを用いて接続すると Web サーバの SSL 関係の環境変数でクライアント証明書の内容が
得られるのでその中にある ID 情報で本人確認ができる。
リスト 3 IC カードログイン認証をする設定
SS LV e ri fy C li ent require
SSL Verify Depth 2 # 京 都 大 学 は 2 階 層
SSLRequire ( %{ SS L _C L IE N T_ S _D N _C N } in { " 全学 ID1 " ," 全学 ID2 " ...} and \
%{ S S L_ C LI E NT _ S_ D N_ O U } eq " Kyoto University Faculty CA " and \
%{ SS L_C LIE NT_ S_ DN_ O } eq " Kyoto University " and \
%{ SS L_C LIE NT_ S_ DN_ C } eq " JP " ) # こ こ で 証 明 書 を 制 限 す る こ と も 可 能
SSLOptions + StdEnvVars \ # C G I な ど で S S L 関 係 の 環 境 変 数 が 利 用 可 能
+ FakeBasicAuth # B a s i c 認 証 と 併 用 も 可 能
# 以 下 は Basic認証と併用する場合
AuthName " ICcard auth "
AuthType Basic
A u t h B a s i c P r o v id er file
AuthUserFile " / path / to /. htpasswd "
require valid - user
# / path / to /. h t p a s s w d に は 下 記 の よ う に 全 学 I D を 羅 列
# / C = JP / O = Kyoto University / OU = Kyoto University Faculty CA / OU = Regular / CN = 全 学 ID1 : xxj31ZMTZzkVA
# # こ こ で ’ xxj31ZMTZzkV ’ は文字列 ’ password ’ の D E S ハ ッ シ ュ 値 で 固 定 値
5.3 利用者からの要望と対応
IC カード及び電子証明書を用いた IC カード認証 (多要素認証) は人事給与等の Web サービスで運用中である
が、Web ホスティングサービスに対しては、まだ利用者へのアナウンスが十分でない。本方式はより高いセキュ
リティが必要となるコンテンツには有効な手段であるので利用者にその旨アナウンスしていきたい。
6 まとめ
Web ホスティングサービスに対して統合認証基盤を適用させ、以下の事を明らかにした。
• セキュリティに関して
(1) ファイル更新時の ID の使い回しを抑制ができた。
(2) IC カード認証でより高いセキュリティが必要になる Web コンテンツの保護が可能になった。
• 利用者の利便性に関して
(3) ファイル更新時の ID を統合認証基盤の全学 ID に変更し、複数のサイトの更新も可能になった。
(4) 全学 ID 及び Shibboleth システムにより、Web シングルサインオン環境が提供できた。
今後、システムの安定運用に加え、Shibboleth システムや IC カード認証について利用者の認知度を向上させ利用
を促進する。また対応事例を増やすとともに、安全性や利便性の観点から有効性を検証していく。
参考文献
[1] Shibboleth http://shibboleth.internet2.edu/
[2] Apache http://httpd.apache.org/
[3] ProFTPD http://www.proftpd.org/