axies nagai-20151202
TRANSCRIPT
熊本大学統合認証基盤における ユーザ属性の管理
大学ICT推進協議会(2015/12/2)
永井 孝幸（熊本大学）
学認の運用に必要なユーザ属性
• eduPersonPrincipalName(ePPN)
–利用者を一意に識別するID
• eduPersonAffiliation(ePA)
–ユーザ区分(教員/職員/学生)
– メールアドレス(一部SPの利用に必要)
大変なのは運用体制の整備(特にAMの方)
• 7学部・10000ユーザ(学生：8000,教職員:2600)
• 組織として属性値の正しさをどう保証するか
• 各属性値をどうやって更新管理するか
← Identity Management
← Access Management
熊本大学での学認への取り組み
• テストフェデレーション参加(2008)後、停滞
– SSO認証基盤としてCASを導入済み(2006)
• SSO基盤として二重投資するメリットが不明
–身分・契約毎にIDを発行
• 中期計画にて生涯ID(熊大ID)導入策定(2010)
–運用フェデレーション参加(2013)
– CAS・Shibboleth統合(2014)
1. ePPNには使えない
2. ユーザ種別をIDで区別
熊本大学ID導入プラン
• 英字＋数字からなる9桁のランダムID
–例：AB0123456 教職員・学生番号IDと名寄せ
1. 学認対応
– IdPはAXIOLE(≒ShibbolethIdP+uAppove)
2. 認証ゲートウェイ構築(CAS・Shibboleth統合)
–ログインIDとユーザIDを分離→透過的移行支援
熊本大学の学認用IdP
• AXIOLEアプライアンスによる冗長構成
– Shibboleth IdP + uApproveJP相当
–学認用属性定義は一部JavaScriptを利用
eduPersonPrincipalName属性定義(抜粋)
• 熊本大学IDのハッシュ値をePPNに使用
– uid属性からePPNを動的生成
<ad:Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
importPackage(Packages.org.apache.commons.codec.digest);
salt = ********;
scope = "@kumamoto-u.ac.jp";
uniqueValue = uid.getValues().get(0) + salt;
localpart = DigestUtils.md5Hex(uniqueValue);
eduPersonPrincipalName = new BasicAttribute("eduPersonPrincipalName");
eduPersonPrincipalName.getValues().add(localpart + scope);
]]></ad:Script>
eduPersonAffiliation属性定義(抜粋)
<ad:Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
eduPersonAffiliation = new BasicAttribute("eduPersonAffiliation"); eduPersonAffiliation.getValues().add("member");
if (typeof memberOf != "undefined" && memberOf != null ){
count = memberOf.getValues().size(); shibPrefix = "cn=shibboleth"; shibPrefixLength = shibPrefix.length;
facultyGroup="cn=shibboleth:faculty,ou=kugroups,dc=kumamoto-u,dc=ac,dc=jp";
staffGroup="cn=shibboleth:staff,ou=kugroups,dc=kumamoto-u,dc=ac,dc=jp";
studentGroup="cn=shibboleth:student,ou=kugroups,dc=kumamoto-u,dc=ac,dc=jp";
for ( i = 0; i < count; i++ ){
value = memberOf.getValues().get(i);
if(value.substring(0,shibPrefixLength) != shibPrefix) continue;
if(value == studentGroup) eduPersonAffiliation.getValues().add("student");
else if(value == facultyGroup) {
eduPersonAffiliation.getValues().add("faculty"); eduPersonAffiliation.getValues().add("staff");
} else if(value == staffGroup) eduPersonAffiliation.getValues().add("staff");
}
}
]]></ad:Script>
• 所属LDAPグループに応じて属性値を動的割当
• memberOf属性からePA属性を動的生成
• グループ管理にGrouperを利用(後述)
アカウント原簿の作成
• 人事給与DB＋学務DBからデータ集約
–熊大IDひもづけ：ID管理システムで毎月名寄せ
– メールアドレス：「kumamoto-u.ac.jp」のみ収集
改組前のデータが
大量に・・・ とりあえず手作業で・・・
毎月名寄せ
学認用グループの定義
• 教員・職員・学生って一体誰のこと？
–付属学校の教職員は？附属病院のスタッフは？
– TAは職員？
• 雇用契約上は「有期雇用職員」
• 対外的にも「熊本大学の職員」とみなす？？？
• 幽霊職員問題(卒業したTAが帳簿に残存）
–電子ジャーナル利用契約との整合性
• 現状
– 「学生＋常勤の教職員」で運用開始(2013/12)
–その他のケースはWGで審議
学認運用グループ検討WG
• 職員証の発行対象なら職員と見なす – 「医員」「医員(研修医)」「特定事業研究員」も「職員」
• 原則、附属病院のスタッフは電子ジャーナル利用資格あり
• 付属学校の教員は熊大の教職員として特に区別は無い
部局 担当
総合情報基盤センター 情報セキュリティポリシーとの整合性確認
附属病院 各種医療関係スタッフの扱い
教育学部 教育学部付属幼稚園・小学校・中学校の扱いについて
教授システム学専攻 科目等履修生、JICA留学生
附属図書館 図書館規定・各種契約との整合性確認
情報企画ユニット 学内規則との整合性確認・事務局内連絡
人事DBでは分からないケース
• 外国人特別研究員
– 大学と雇用関係は無い。人事DBに出てこない。
→部局代表者を通じて学認の利用申請
• 非常勤講師
–無給のケースもある
–業者と契約して派遣されるケースもある
• TA
– 「ティーチングアシスタント」職種だけではない • 雇用資金によっては「事務補佐員/技術補佐員」
→「学生アルバイト」属性を別途管理
Grouper
• Internet2発祥のグループ管理用ツールキット
–グループ毎に管理者割り当て可能
– DBデータ取り込み→グループ更新→LDAP同期
• グループ定義に和集合・差集合が使える
–基本グループから学認用グループを合成
Grouperによる学認用グループ定義
• 教員＝∪(各種教員)ー{テストID}ー{学生バイト}
• 職員＝ ∪(各種職員)ー{テストID}ー{学生バイト}
faculty = (faculty includes) －(faculty excludes)
運用状況(2015/11時点)
• 熊本大学ID： 62,435件発行(うち欠番94件)
–教職員(1997年度以降),学生(1999年度以降)
–自動名寄せ失敗は月に数件(カナ氏名表記揺れ)
• ユーザディレクトリ
–学生：学部・学科・学年・専攻(201グループ)
–教職員
• 職種 (169グループ)
• 所属部局・係・講座(511グループ)
–開講科目受講生・教員グループ(17518グループ)
Grouperの使い勝手
• 導入
–大変。J2EE開発者/ソースコード読める人向き。
• 機能
–十分。ただしUIが英語。REST API対応。
• Grouper→LDAPの夜間同期
–差分同期は数分。一括同期だと約1時間。
– slow query(>120s)が出る。Viewを多用。
–サブクエリ多用→MySQLよりPostgresqlが良好
duration: 122991.146 ms execute <unnamed>: select count(*) as col_0_0_ from grouper_memberships_all_v membership0_
まとめ
• バックエンド整備:Shibboleth/LDAP/Grouper
– ePAはmemberOf属性から動的生成
• 「お金の流れ」と「情報の流れ」は別物
–人事DBは「雇用契約管理用」でしかない
–学認運用グループ検討WGにて議論
• 情報アクセス制御のためのグループが必要
–雇用契約・在籍情報だけでは不十分
– 「担当業務」の掌握が必要
• 根は深い
–組織として「業務範囲」の管理ができていない