<4D F736F F F696E74202D208CB B835E5F88EA95B68DED8F9C8DCF5F456D61696C8DED8F9C5F53538CA E937891E63189F189EF8D F89AA91E58A7782AA94468FD88AEE94D582C98B8182DF82E997768C8F288E518FC6295F

Transcription

1 福岡大学が認証基盤に求める要件 福岡大学総合情報処理センター准教授中國真教 もくじ 福岡大学のご紹介 福岡大学における認証基盤の歩み 福岡大学が認証基盤に求める要件 認証基盤の刷新 2つのSSOの導入 新たな課題 まとめ 2

2 福岡大学のご紹介 3 福岡大学の紹介 本部所在地 福岡市城南区七隈 キャンパス 七隈 北九州学術研究都市 組織 9 学部 31 学科 10 研究科 7 付置研究所 15 センター 2 つの大学病院 2 つの附属学校 規模 学生数約 21,000 人 ( 卒業生数約 23 万人 ) 教職員数約 3,000 人 福岡大学公式ホームページ 4

3 現在認証基盤の導入検討と構築を開始 福岡大学における認証基盤の歩み 5 福岡大学における認証基盤の歩み (1/5) 認証基盤を刷新し 運用開始 認証基盤システムに紐付くシステム数は 20 以上 登録者数は約 24,000 人 福岡大学における認証基盤の歴史過去 福岡大学統合認証システム と命名 2004 年 4 月 2003 年 7 月 統合認証システムの運用開始 8 つのシステムの ID とパスワードを一元化 IC カード学生証 職員証も導入 Shibboleth 1.0 リリース 2005 年 4 月 年 2 月 JAL が IC チェックインサービスを開始 次期の認証基盤の導入検討と構築を開始 福岡大学認証基盤システム と命名 年 10 月 年 5 月 学認 試行開始 学認 本格運用開始 6

4 福岡大学における認証基盤の歩み (2/5) 統合認証システム ( 旧認証基盤 ) と紐付いていたシステム (Web サービス ) の代表例 大学ポータルサイト 教育研究システム (e-learning システム Microsoft Live@edu その他 ) ネットワーク認証 検疫システム 図書館利用者向けサービス (My ポータル ) SSL-VPN サービス ウィルス対策システム ( インストール時の認証 ) グループウェアサービス シラバス関連システム 出張申請システム 研究者情報システム 下線のあるシステムは旧認証基盤で SSO 機能実装済み 7 福岡大学における認証基盤の歩み (3/5) 旧システムの課題 ( 利用者から見た側面 ) パスワード変更時のリアルタイムな反映ができない パスワード変更が反映されるのは次の日 パスワード忘れに対する対応窓口のトラブル パスワード初期化の依頼者の行列ができることも! 学外からパスワード変更をさせないポリシー 利用者の意見としては パスワード変更のために大学に来るのは面倒! 諸事情により来られない場合もある! とのこと 8

5 福岡大学における認証基盤の歩み (4/5) 旧システムの課題 ( 管理者から見た側面 ) システムの機能拡張が困難 ソフトウェアは機能拡張を意識した造りになっておらず 機能拡張のたびに大きな改修が必要 システムがブラックボックス化していた 仕様がわかりにくく 保守性に問題があった パスワードとして使用できる文字種が少ない 旧システムと連携していたシステムでは アルファベットと数字しか使えず 記号が使えなかった 9 福岡大学における認証基盤の歩み (5/5) 旧システムから新システムへの移行についての課題 現行の ( 疑似 )SSO を今後どのように取り扱うのか? 選択肢 : 今後も使う or 今すぐ捨てる 検討結果 : もう暫く使ってから捨てる 既存の疑似 SSO の仕組みを今後も踏襲するべきではないことは理解できるが 過去の遺物を今すぐには捨てられない 新たに構築する SSO と疑似 SSO を平行して利用することに決定 10

6 福岡大学が認証基盤に求める要件 11 福岡大学が認証基盤に求める要件 利用者への負担の軽減 ID 申請の電子化 ( 常勤の教員 職員の申請 ) パスワード管理に関する負担軽減 パスワード変更時の全システムへの即時反映 SSO への対応 連携するシステムとの親和性 標準的な技術を用いた汎用性の高いシステムとする 上位システム ( 利用者情報を保持する人事給与システムや教務システム ) から受け取る利用者情報の適切な処理 高い拡張性 ベースとなる部分は 2012 年から 10 年間利用する予定 必要に応じて機能拡張を実施する予定 12

7 認証基盤の刷新 13 認証基盤の刷新 ( ハードウェアの外観 ) 14

8 認証基盤の刷新 (ID/ パスワード編 )(1/4) 利用者への負担の軽減 ID 申請の電子化 ( 常勤の教員 職員の申請 ) 1 着任日に仮 ID を書面で通知 2 仮 ID を元に本 ID を電子申請 ID 申請者 3 申請内容を確認後 承認 認証基盤管理者 従来行われていた 申請者による申請書作成や提出 認証基盤管理者による申請書の煩雑な処理が不要になった 15 認証基盤の刷新 (ID/ パスワード編 )(2/4) 利用者への負担の軽減 パスワード管理に関する負担軽減 (1) パスワード初期化端末の導入による 初期化手続きの高速化 依頼者が所有する IC カード学生証をかざすことで 初期化対象者を容易に検索でき 利用者からの依頼へ迅速に対応できるようになった ( 一人あたりの対応時間は 2 分から 1 分へ短縮 ) 16

9 認証基盤の刷新 (ID/ パスワード編 )(3/4) 利用者への負担の軽減 パスワード管理に関する負担軽減 (2) 学外からパスワードを変更する際には ワンタイムパスワードを併用し 2 要素認証によって利用者を認証する仕組みを導入 認証基盤システム 利用者が予め登録しておいたメールアドレスへワンタイムパスワードを通知 利用者が所有するスマートフォンなど パスワードの有効期限を迎える日に 海外への長期出張 ( 在外研究など ) 留学 長期休暇などのため大学から離れた場所に居た場合でも パスワードが失効することなく ID を継続して利用できるようになった 17 認証基盤の刷新 (ID/ パスワード編 )(4/4) 利用者への負担の軽減 パスワード変更時の全システムへの即時反映 旧認証基盤では パスワード変更を行っても 新しいパスワードが有効になるのは次の日以降であり 何かと不都合が生じたため 即時反映を可能にする仕組みを導入した パスワードを他人に知られたかもしれないのでパスワード変更をしたけれど 反映が次の日だと 今日は誰かが不正にログインする可能性があるなぁ セキュリティ面の課題が解決しただけでなく パスワード変更直後に新しいパスワードが有効になっているかを即座に確認できるようになったため 利便性が向上した 18

10 認証基盤の刷新 (SSO 編 )(1/4) SSO への対応 過去の遺物 ( 疑似 SSO) との連携 ( 共存 ) 方法は? SSOで連携するWebサービスの選定は? SSO を実現するためにどの製品を使うのか? 19 認証基盤の刷新 (SSO 編 )(2/4) SSO で連携する Web サービスの選定 どのような視点で選定する? 利用者数が多いシステムを優先 候補となったシステム 大学ポータルサイト (FU ポータル ) Microsoft Live@edu (Outlook Live) e-learning システム (HIPLUS Moodle) ネットワーク認証 検疫システム 図書館利用者向けシステム (My ポータル ) ログイン時にメールアドレス ( 長い文字列 ) の入力が必要であるため 利用者から不評だった 20

11 認証基盤の刷新 (SSO 編 )(3/4) SSO 製品の選定 Shibboleth を選択 理由 : 国立情報学研究所や他大学から提供されているサービスを活用しやすくするため しかし Shibboleth では不安な点も 運用実績がそれほど多くない ( 只今 増加の最中 ) 今後 市場に出回るシステムは Shibboleth( SAML ) への対応をどのように考えているのか不明 21 認証基盤の刷新 (SSO 編 )(4/4) Shibboleth 導入についての懸念 SAML 非対応のシステム ( アプリケーション ) は改修が必要だが 開発者が改修に応じてくれるとは限らない ( 自力で改修できれば良いが ) SAML 対応への改修にはコストがかかるかも? Shibboleth の標準機能では 認証方式が ID/Password 方式であるため 将来的に Desktop SSO やクライアント証明書による SSO の機能の導入が必要になった場合は Shibboleth では実現がやや難しい 改修できたとしても Shibboleth がバージョンアップした際には その対応のために再度改修が必要となり コストが増大する可能性がある 22

12 2 つの SSO の導入 23 2 つの SSO の導入 (1/9) OpenAM と Shibboleth の導入 学外サービス () へのアクセスには 学内サービス () へのアクセスには 24

13 2 つの SSO の導入 (2/9) なぜ OpenAM なのか? OpenAM はシングルサインオンの方式を複数備えている ( 実は SAML にも対応 ) 側の改修費用は Shibboleth と連携させる場合よりも安く抑えられる 多様な認証方式を用意 ID/ パスワード認証以外にも認証方式を標準で備えており システムのセキュリティや用途にあった認証方式の選択が可能 25 2 つの SSO の導入 (3/9) 2 系統の SSO OpenAM OpenAMによる SSOの連携範囲 OpenAM Shibboleth Shibbolethによる SSOの連携範囲 Shibboleth OpenAM ID/PW の入力 Shibboleth ID/PWの入力 SSO の系統が異なるため それぞれの SSO の系統での ID/ パスワードの入力が必要 26

14 2 つの SSO の導入 (4/9) SSO なのに 2 回も認証が必要なの? こんなの SSO とは言えない! ID/PW の入力 ID/PW の入力 この問題を解消するために OpenAM と Shibboleth の連携を検討 Rest API により Shibboleth が OpenAM に認証済みかどうかの問い合わせを行うことで Shibboleth IdP の認証を OpenAM で実現! 27 2 つの SSO の導入 (5/9) OpenAM と Shibboleth によるハイブリッド型 SSO の実現 OpenAM による SSO の連携範囲 OpenAMとShibboleth IdP の連携 Shibboleth による SSO の連携範囲 OpenAM OpenAM OpenAM Shibboleth Shibboleth Shibboleth ID/PW の入力 1 度の ID/ パスワードの入力で OpenAM と Shibboleth の両系統のリソースにアクセスできる 28

15 2 つの SSO の導入 (6/9) OpenAM と Shibboleth の認証連携 Shibboleth OpenAM OpenAM リバプロ OpenAM IdP Shibboleth IdP SAML 学認 (NII) SAML 対応ではない既存システム ヘッダー認証や代理認証 Rest API による認証連携 SAML Shibboleth ID/PW の入力 29 2 つの SSO の導入 (7/9) ハイブリッド型 SSO における Shibboleth へのログインシーケンス 利用者 OpenAM Shibboleth IdP Shibboleth (1)Shibboleth にアクセス (2)SAML 認証要求 (3)OpenAMへリダイレクト (4)OpenAMログイン画面表示 (5)ID/PW 送信 (6)Shibboleth IdPへリダイレクト Token ポイント 1 Shibboleth の外部認証機能を利用 (ID とパスワード入力は全て OpenAM で実施 ) ポイント 2 OpenAM と Shibboleth IdP の連携 (OpenAM 連携モジュールにより実現 ) (8) 問い合わせ結果 (9)SAML 認証応答 (SAMLアサーションを含む) (7)OpenAM で認証されたユーザであるかを OpenAM へ問い合わせ (10)Shibboleth のコンテンツを利用者へ送信 30

16 2 つの SSO の導入 (8/9) 今回構築したハイブリッド型 SSO の特長 ( まとめ ) OpenAM と Shibboleth が認証連携 OpenAM 側で利用者認証が完了すれば Shibboleth と連携しているサービスにも SSO が可能 (Shibboleth の外部認証機能を利用 ) OpenAM の多様な認証方式 (PKI 認証 ワンタイムパスワード等 ) や柔軟な認可機能を利用して サービスのセキュリティレベルに応じたアクセス制御が可能 Shibboleth に対応するための改修は不要 SSO 基盤の構築は オープンソースのみ で実現 LDAP サーバは OpenLDAP リバースプロキシサーバは Apache + OpenAM Policy Agent 31 2 つの SSO の導入 (9/9) ログイン画面 GakuNin Ready! のマーク入り! 32

17 新たな課題 33 新たな課題 (1/3) 福岡大学図書館からの要望 ( 認証基盤システム構築中の 2011 年 11 月頃の話 ) SSO 機能だけでは魅力がない! SSO 機能だけでは 図書館利用者向けシステム (My ポータル ) は利用されない 図書館から利用者へ伝えたい情報が伝えられない状況 SSO 機能を利用したマッシュアップ (MashUp) を図書館へ提案 34

18 新たな課題 (2/3) 大学ポータルと図書館利用者向けシステム (My ポータル ) のマッシュアップの提案 図書館 My ポータル イベント案内図書予約システムの利用説明会を開催します 図書の貸出状況西洋の政治の歴史 返却延滞日数 10 日 大学ポータルの画面内に図書館 My ポータルの画面の一部が表示されることで My ポータルに直接アクセスしなくても My ポータルから提供される情報も同時に得られる 35 新たな課題 (3/3) クラウドサービスとの連携 Office365 for Education(Live@edu の後継 ) との認証連携における課題 Office365 for Education のポリシーでは パスワード変更後のパスワード有効期限は 90 日! 福岡大学認証基盤システムと Office365 におけるパスワードポリシーの違いに困惑! 後に Microsoft 側のポリシーの緩和により無期限で設定できるようになったが 今後変更になる可能性は否定できない クラウドサービスと連携する際はこのような点にも注意が必要 36

19 まとめ 37 まとめ 利用者への負担の軽減 OpenAM と Shibboleth によるハイブリッド型 SSO の構築 導入するシステムが OpenAM か Shibboleth のいずれかに対応していれば安価に SSO 可能 SSO の輪を広げやすくすることが狙い SSO を生かした新サービスの提案 SSO 機能だけでは魅力に欠けるという声 マッシュアップの検討 クラウドサービスとの連携には要注意! 38

20 ご清聴ありがとうございました 39