JICS2013レポート(1) 3/4午前 学認シンポジウム

3月4日〜5日、Japan Identity & Cloud Summit(JICS)に参加してきました。今回はNIIとOpenID Foundation Japanの共催で、産官学が集結する日本初のidentity summitとなったそうです。

4日はGeneral Track、5日はOpenID Hackathonを中心に参加しました。

当日取ったメモを公開します。間違いや発言意図と違うなどありましたらご指摘お願いします。

学認トラストフレームワーク

• 東京大学 佐藤さん
  • 資料

• 学認とは
  • トラストフレームワークプロバイダ(TFP)でありトラストフレームワーク(TF)
  • IdPはTF/TFPのもとで対外的な信用を主張可能

• 学認の定義
  • SSOの運用主体
  • 参加・運用ポリシーを定める
  • 参加申請
  • 正しく運用されているかチェック(アンケート)

• 学認はself-containedなTF
  • 学認の与える漠とした信頼
    • 学認に入ってIdPを運用している機関は信頼できる
    • 学認に入ってSP(RP)を運用しているところは信頼できる
  • OIX (OpenIdentityExchange)

• TFの御利益
  • SPはIdPのLoAについて一定の保証を得られる
  • RPのサービスポシシー・セキュリティーポリシー・プライバシーポリシーの評価について一定の保証が得られる
  • なんとなくの信頼ではなく監査による信頼性の保証
  • OIXが学認のトラストチームを認定

• OIXと学認
  • OIX: OpenIdentityExchange
• 学認とOIX
  • 学認はOIXにspecial providerとして参加
  • OIXは「学認のIdPに対してFICAM LoA1認定を行うアセッサ」を学認内で指定する

• LoA1
  • 世界標準
  • レベル1〜4
  • 認定基準
    • Governance(成熟度), Privacy, Technical
  • OIXの審査基準を適用
  • 学認の場合
    • 学認アンケートにポジティブな答える出ればLoA1はOK

• 学認アンケート
  • 組織の成熟度(Governance)を調査する手段
    • きちんとIdPを運用しているか。文書化されているか
  • Identity管理
  • パスワード管理
  • プライバシー
  • テクニカル

• 学認アンケート
  • おおむねpositive
  • 運用スコアつけてみた

学認R&D 2013春モデル

• 佐賀大学 大谷さん
  • 資料
  • 学認のサービスをより便利にするために

• 学認申請システム
  • 申請と最低限のメタデータ生成の機能しかなかった
  • 2012年の改良
    • 申請
      • OpenIdP対応
      • 運用責任者による電子的な確認
      • アンケート
    • メタデータ: DSと連携
    • attribute-filter.xml

• OpenIdP対応
  • これまでは申請のためのアカウントをローカルに発行(メアド、パスワード)
  • → OpenIdPで認証可能に
  • OpenIdP: IdPを構築していない組織の人たちが試験的に利用できる
    • 学認サービスの一部を利用可能

• 運用責任者
  • 副運用担当者が指定可能: eppnがあれば主担当者が確認済みにできる

• 学認アンケート機能

• メタデータテスト作成

• mdui対応
  • SAML V2.0 Metadadata Extensions for Login and Discovery User Interface Version 1.0
    • IdPを見つけやすくなる
  • mdui:DisplayName, Description, Keywords, Logo, PrivacyStatementURL
  • IPHint, DomainHint, GeolocationHint
    • ログイン時のIPアドレスやgeoロケーションでDSを選択
• attribute-filter
• 利用可能なIdP/SPの設定を固別に可能
  • IdPに対応していないSPを非表示

ケーススタディー中小大学の例

• 北見工業大学 升井さん
  • 資料
• 北見工業大学とは
  • 北見: 札幌まで300km 特急で4時間半
  • 1学部(工学部)/6学科の単科大学
    • 教職員300人、学生・大学院性2300人
    • 必要なライセンス数2600〜3500

• かかえていた問題
  • 業務サーバーがばらばら → ID/PWもばらばら
  • LMS,教務管理、語学演習、図書館、物品請求、出張申請、サイボウズなどなど

• 採用したソリューション
  • SSO・ID統合管理: OSSTech OpenAM、代理認証、Shibboleth連携
  • ID統合管理: LDAPマネージャー
  • サーバー統合、仮想化

• SSO対応
  • 外部認証非対応なもの: LDAPが引けないなど
    • 教務管理、物品請求、出張申請
    • LDAPからCSV出力 → インポート
  • 学外のサーバー

• データの流れ
  • 教職員: 人事データ → LDAPマネージャ → 各システム(一部CSV・手入力)
  • 学生データ: 入試データ → Campus Square → LDAPマネージャ
    • Campus Square: CSVでID, PWをインポートできないのでまずこいつに入れる
    • 4月1日に学籍番号が振られてから遅滞なくID連携しないと履習ができない。1日2日の勝負。パラレルに処理する

• 「ID連携する」と言うとアブナクなるんじゃないかという心配が出るので学内に説明が必要だった

• SSO実装の方針: SSO 代理認証方式、チケットで

• 導入までのタイムライン
  • 2009.9 認証に関する学内調査開始
  • 2009.12 マスターDBの作成: 名寄せ作業はNDAの上で外注、教職員は教職員番号のないDBもあったので手作業が頼り
  • 2010.3 SSOについてのモデル策定、システム更新の仕様策定
  • 2010.7 入札公告
  • 2011.3 システム稼動

• 苦労話
  • 重要なサーバほど、古くて融通が効かない → Win2000だったり
  • 事務職員の配置転換(3年) → システムに精通している人がいなくなる
  • 学内への接し方: まあまあ、あの先生がそうおっしゃるならという気の使い方が重要

• Shibboleth連携
  • 学内SSOにログイン後、Shibboleth連携ボタンをクリック
  • 本学SPを立て、そこから本学IdPでいったん認証、そのセッション情報をクライアントへ送信

高専のID連携

• 高等専門学校機構 神(じん)さん
  • 国立高専の紹介: 50周年
    • 国内に51高専ある。ロボコンで有名

• 高専の情報基盤整備
  • 平成16年度から独立行政法人化(高専機構)
  • 第三期に予算が1/3しかもらえなかった

• 校内LANシステム更新計画(平成21年度)
  • 交付金から予算を念出 → リースで(平成24年〜25年)
  • スケールメリットを活かした戦略的な整備
  • 一定基準で同一物品を機構本部が一括して調達
    • まずfirewall, 認証サーバーから → 次のリースからは全部を一括調達にしたい

• ID管理
  • 高専共通システム、各高専設置の校内システム
  • ユーザーIDはドメインつきとし、かぶらないように

• 認証サーバ
  • OpenLDAP, FreeRADIUS, Shibboleth, UnifIDone
  • 富士通ユニファイドワン(UnifIDone)

• IDサーバー機能
  • 教職員のデータのみ、30分に1回、各高専サーバーと機構サーバーで同期
  • パスワードポリシーの統一

• 学認連携をどうしたいか(アイディア段階)
  • 学認と高専設置サーバーで連携
  • 全51高専から接続
  • 平成26年から使える予定
  • 高専サーバーから学認サーバーへの個人属性情報送信する
    • ?uApprove.jpを利用 or ?ログイン画面にポリシー表示
    • どっちにするか検討中

• 今後のとりくみ
  • LANケーブルが古い(お金がなくて買えない)ところさえある!
• まとめ
  • 各校内システムとの認証連携を随時開始
  • Web給与明細システムの連携ができた

eduroam

• 東北大学 曽根さん
  • 資料

• eduroamとは
  • 大学・研究機関間国際無線LANローミングアクセスサービス
  • International Roaming Access Service for High-Educationで「いろは」
  • 個人ごとのアカウント/パスワードで認証を受けて安全に接続
  • SSID「eduroam」で802.1x方式
    • Radius認証
      • 自組織realm → IDデータベースを見る
      • 他組織realm → 問合せを上位へ転送 → 認証してもらう
  • 国際的な適合条件

• キャンパス無線LANのアクセスローミング
  • キャンパス無線LAN: 教職員、学生、演習など
  • 来訪者のキャンパスネットワーク利用

• セキュリティー
  • 安全で使いやすくて安定、WPA2/AES
  • 個人認証 → インシデント時の追跡
  • 強固すぎるとかえって使いにくい
  • 教職員・学生で数万人規模になる大学も! → スケーラビリティー
  • 教員ですべてをカバーしようと考えないことが重要

• 世界共通無線LANローミング
  • 世界中の機関で共通: ベンダロックインされない
  • 億人のレベルになる → 認証連携による所属機関のアカウントで利用

• eduroam
  • ヨーロッパのTERENAで開発
  • EU40か国、au, nz, hk, tw, cn, jp, ca, us, ru
  • 日本: 2006年東北大学が初導入、NIIと共同で運用・技術開発
  • www.eduroam.jp

• eduroamの認証連携
  • この段階ではまだ学認と関係ない
  • 機関RADIUSサーバー → 国内RADIUSプロキシ → トップレベルRADIUSプロキシ
    • トップレベルはEU, AsiaPacificにある
  • IEEE802.1x認証
  • クライアント証明書による認証(EAP-TLS)も研究開発中

• eduroamの参加方法
  • 学内にIdPとアカウント配布
  • RADIUS IdP + RADIUS Proxy
    • 別案(代理認証システム、仮名アカウント発行システム)
  • 無線LANシステムの整備: 互恵が基本
    • ゲストネットワークを用意

• 無線LANの運用管理
  • セキュリティー
    • 通信内容の暗号化: 共通鍵(WEP) or 利用者認証(主体認証、機器識別)
  • 学内ネットワークの利用資格の例外措置
    • 通常は「本学構成員 + 許可を受けて情報システムを利用する者」
    • eduroamでは個人認証できる → 大学側でeduroamなら個別の許可不要という例外措置
  • 互恵的な無償での提供(非事業)

• 代理認証システム
  • DEAS: Delegate Authentication System
  • RADIUS IdPの機能を代行するアカウント発行ウェブサービス
  • 利用登録した管理者がアカウントをバルク発行 → 配布

• 仮名アカウント発行システム: 学認が前提
  • 個別ユーザが個人用アカウントを随時取得可能
  • 学認システムのみで使える

• 無線LANネットワークの構成・アクセス制御
  • 学内ページを見られるのがイヤだ、電子ジャーナルなどの不正利用されたらイヤだ
  • ゲストネットワークの構築
  • 認証VLAN利用

• 災害に強いキャンパス無線LAN
  • 東日本大震災におけるeduroam
    • 役に立った!

Q&A

• nov: 学認のIdP, SPのホワイトリストを作るという話: 学認側での一括管理の他、参加側で個別にブラックリストを持てるのか
  • 大谷さん: 作成中だが、DSから表示・非表示の制御、attribute-filterに使おうとしている。
  • 中村さん: 自分のIdPに手で設定するのがめんどくさいだろう → 管理者がチェックすれば、自分のサーバーに反映される仕組: 自分のIdPにログインして編集しなくてもいいというコスト削減策

感想

• ケーススタディーの話がとても面白かったです。結構な部分でCSVに頼っているのがわかりました。