大学ICT推進協議会2015年度年次大会の認証連携部会企画セッションの講演スライドです

1. 熊本大学統合認証基盤における
ユーザ属性の管理
大学ICT推進協議会(2015/12/2)
永井 孝幸（熊本大学）

2. 学認の運用に必要なユーザ属性
• eduPersonPrincipalName(ePPN)
– 利用者を一意に識別するID
• eduPersonAffiliation(ePA)
– ユーザ区分(教員/職員/学生)
• mail
– メールアドレス(一部SPの利用に必要)
大変なのは運用体制の整備(特にAMの方)
• 7学部・10000ユーザ(学生：8000,教職員:2600)
• 組織として属性値の正しさをどう保証するか
• 各属性値をどうやって更新管理するか
← Identity Management
← Access Management

3. 熊本大学での学認への取り組み
• テストフェデレーション参加(2008)後、停滞
– SSO認証基盤としてCASを導入済み(2006)
• SSO基盤として二重投資するメリットが不明
– 身分・契約毎にIDを発行
• 中期計画にて生涯ID(熊大ID)導入策定(2010)
– 運用フェデレーション参加(2013)
– CAS・Shibboleth統合(2014)
1. ePPNには使えない
2. ユーザ種別をIDで区別

4. 熊本大学ID導入プラン
• 英字＋数字からなる9桁のランダムID
– 例：AB0123456 教職員・学生番号IDと名寄せ
1. 学認対応
– IdPはAXIOLE(≒ShibbolethIdP+uAppove)
2. 認証ゲートウェイ構築(CAS・Shibboleth統合)
– ログインIDとユーザIDを分離→透過的移行支援

5. 熊本大学の学認用IdP
• AXIOLEアプライアンスによる冗長構成
– Shibboleth IdP + uApproveJP相当
– 学認用属性定義は一部JavaScriptを利用

6. 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>

7. 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を利用(後述)

8. アカウント原簿の作成
• 人事給与DB＋学務DBからデータ集約
– 熊大IDひもづけ：ID管理システムで毎月名寄せ
– メールアドレス：「kumamoto-u.ac.jp」のみ収集
改組前のデータが
大量に・・・ とりあえず手作業で・・・
毎月名寄せ

9. 学認用グループの定義
• 教員・職員・学生って一体誰のこと？
– 付属学校の教職員は？附属病院のスタッフは？
– TAは職員？
• 雇用契約上は「有期雇用職員」
• 対外的にも「熊本大学の職員」とみなす？？？
• 幽霊職員問題(卒業したTAが帳簿に残存）
– 電子ジャーナル利用契約との整合性
• 現状
– 「学生＋常勤の教職員」で運用開始(2013/12)
– その他のケースはWGで審議

10. 学認運用グループ検討WG
• 職員証の発行対象なら職員と見なす
– 「医員」「医員(研修医)」「特定事業研究員」も「職員」
• 原則、附属病院のスタッフは電子ジャーナル利用資格あり
• 付属学校の教員は熊大の教職員として特に区別は無い
部局 担当
総合情報基盤センター 情報セキュリティポリシーとの整合性確認
附属病院 各種医療関係スタッフの扱い
教育学部 教育学部付属幼稚園・小学校・中学校の扱いについて
教授システム学専攻 科目等履修生、JICA留学生
附属図書館 図書館規定・各種契約との整合性確認
情報企画ユニット 学内規則との整合性確認・事務局内連絡

11. 人事DBでは分からないケース
• 外国人特別研究員
– 大学と雇用関係は無い。人事DBに出てこない。
→部局代表者を通じて学認の利用申請
• 非常勤講師
– 無給のケースもある
– 業者と契約して派遣されるケースもある
• TA
– 「ティーチングアシスタント」職種だけではない
• 雇用資金によっては「事務補佐員/技術補佐員」
→「学生アルバイト」属性を別途管理

12. Grouper
• Internet2発祥のグループ管理用ツールキット
– グループ毎に管理者割り当て可能
– DBデータ取り込み→グループ更新→LDAP同期
• グループ定義に和集合・差集合が使える
– 基本グループから学認用グループを合成

13. Grouperによる学認用グループ定義
• 教員＝∪(各種教員)ー{テストID}ー{学生バイト}
• 職員＝ ∪(各種職員)ー{テストID}ー{学生バイト}
faculty = (faculty includes) －(faculty excludes)

14. 運用状況(2015/11時点)
• 熊本大学ID： 62,435件発行(うち欠番94件)
– 教職員(1997年度以降),学生(1999年度以降)
– 自動名寄せ失敗は月に数件(カナ氏名表記揺れ)
• ユーザディレクトリ
– 学生：学部・学科・学年・専攻(201グループ)
– 教職員
• 職種 (169グループ)
• 所属部局・係・講座(511グループ)
– 開講科目受講生・教員グループ(17518グループ)

15. 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_

16. まとめ
• バックエンド整備:Shibboleth/LDAP/Grouper
– ePAはmemberOf属性から動的生成
• 「お金の流れ」と「情報の流れ」は別物
– 人事DBは「雇用契約管理用」でしかない
– 学認運用グループ検討WGにて議論
• 情報アクセス制御のためのグループが必要
– 雇用契約・在籍情報だけでは不十分
– 「担当業務」の掌握が必要
• 根は深い
– 組織として「業務範囲」の管理ができていない