PKI と SSO
CAS 2 による「セキュリティ階層」に応じた認証システム
CAS2 を利用して「アプリケーションの求めるセキュリティレ ベルに応じた認証」を行なう
PKI (X.509) 認証を行なったユーザ
Web Browser
AuthN by X.509
Web Application with Security Level 2
Web Application with Security Level 1 Access granted
Access granded
「ユーザＩＤ・パスワード」認証を行なったユーザ
Web Browser
AuthN by PIN
Web Application with Security Level 2
Web Application with Security Level 1 Access granted
Access denied
CAS
2による「セキュリティ階層」に応じた認証システム
CAS2 を利用して「アプリケーションの求めるセキュリティレ ベルに応じた認証」を行なう
PKI (X.509) 認証を行なったユーザ
Web Browser
Web Application with Security Level 2
CAS Server 1. Access with client certificate
2. Redirection ST
TGC with Level 2
「ユーザＩＤ・パスワード」認証を行なったユーザが PKI 認 証を要求された場合
Web Browser
Web Application with Security Level 2 1. Access
2. Redirection
IdM とは
「ドメイン」における「サブジェクト」の「属性」の「管理」
「ドメイン」 ＝ 「組織」
「サブジェクト」 ＝ 「ユーザ」
「属性」 ＝ 「ユーザ属性」, 「Role」, . . .
「管理」
サブジェクト生成 (Provision) 伝達 (Properfate)
利用 (Use)
保守 (Maintain)
サブジェクト消去 (Deprovision)
認証基盤の基本データベースを整備すること
IdM のライフサイクル
この「ライフサイクル」を適切にまわしていけるか？
IdM に求められる機能
Establishing Identity + Provisioning
アイデンティティ情報を実在の人物と関連づけ, 正しい属 性情報を投入して, アイデンティティレコードを作成する プロセス
Authentication Authorization Single Sign On
Enterprise Directory
アイデンティティ情報を認証・権限管理プロセス, 参照リ ポジトリに提供する
Federated Identity
なぜ IdM なのか？
旧来の「全学ＩＤ」を「名古屋大学ＩＤ」に変更 職員番号・学籍番号をもとにＩＤを作成
ＩＤそのものにセキュリティ的な欠陥が存在
「職員番号 ＝ 共済組合番号」である
同一人物が複数のＩＤを所有する場合が発生 身分の変更がＩＤの変更をもたらす
全学ＩＤに基づくサービスの継続が困難 卒業生・退職者には対応困難
頑張ればＩＤの移行は難しくないと思っていた
全学ＩＤから名古屋大学ＩＤへの移行（技術的な側面）
技術的には
LDAP の場合には search filter を
(uid=%s) から (|(nagoyaunivid=%s)(zengakuid=%s)) に CAS の場合には LDAP lookup filter を同様に変更
「こんなこと簡単じゃん！」
情報サービスアプリケーションが業者に委託されているた め, この程度の変更も意外に困難
でも本質はここじゃない！
名古屋大学ＩＤの導入
「生涯にわたって有効なＩＤ」として導入 卒業生・退職者にも対応する
身分に関わらず同一のＩＤ体系を使用 身分は属性情報とする
名古屋大学ＩＤに基づくサービスの継続性を確保
身分の変更に関わらず同一の電子メールアドレスが利 用可能
同一人物が複数の「全学ＩＤ」を持っている可能性がある 例：大学院生＋非常勤講師 (RA/TA), 複数学部で非常勤講 師をやっているなど
名古屋大学ＩＤの導入（つづき）
「名寄せ」は終了しているつもりだった
時期を同じくして次のプロジェクトが存在していた 職員証の IC カード化
→ 対象職員の名古屋大学ＩＤ必要
全学メールサーバ（主に学生向け）の更新
（名古屋大学ＩＤ対応と「氏名」を利用したメールアドレ スへの変更）
対象者を名古屋大学ＩＤサーバで調べてみると問題点が大量 に発覚
「名寄せ」の結果が信頼できない
氏名（漢字やアルファベット表記）がメチャメチャ
再度の「名寄せ」
全学ＩＤ・名古屋大学ＩＤともにデータの発行元を調べる 教職員：人事ＤＢ
学生：学務課ＤＢ
その他にも大学構成員が存在している（研究生・パート職員 など）
大学構成員の全てを捕捉する方法は？
名寄せのキーになる「氏名表記」・「生年月日」が信頼できない 再度の名寄せに１ヶ月かかった
約 44000 エントリ（37000 人）中 11000 エントリ
何が問題なのか？
旧態依然の事務組織の影響を受けている
各部署が自分たちが対象とするデータのみを管理 その結果, 抜け落ちる人, 重複する人が多発
各情報システムが独自に DB を管理していることの名残り
IdM で最も重要なこと
「情報システムの全ユーザ］（＝「大学の全構成員」＋ α）を 正しく捕捉すること
ユーザの属性情報を正しく格納すること 氏名・所属・身分など
身分はシステムへのアクセス権限に関連している
ユーザの基本属性情報（氏名・所属・身分）等の責任部署を明 確にする
人事ＤＢ・学生ＤＢ
その他のユーザは「部局」で管理してもらう
「Provisioning」を適切に行なうことが重要！
Provisioning の一つの流れ（教職員の場合）
「生涯ＩＤ」なので, 以前の名古屋大学ＩＤの確認が必要 電子メールなどは赴任前に利用を開始したい場合がある
職員証・学生証発行
「身分証」には「正しい文字を使いたい」ユーザが少なくない
「履修者名簿の氏名も正しく表記してほしい」という意見も 人事ＤＢ・学生ＤＢなどは Windows ベースになっている
利用できる文字コードは CP932
学生証は「外字」を作って対応← こんなの際限がない！
ＤＢやアプリの Unicode 化を進める必要がある
氏名のアルファベット表記も正しいものを格納する必要がある
「氏名表記」の対応
LDAP の氏名属性に複数の表記を格納 (encoding: UTF-8) 文字セットを CP932 に限った漢字表記
Unicode の範囲の漢字表記 カタカナによるヨミ
ASCII によるアルファベット表記
文字セットを ISO-8859-15 に限ったアルファベット表記
問題点：「Unicode による入力をできるシステムは？」
MacOSX, Windows Vista などが必要 これでも話はおわらない
「氏名表記」の対応（つづき）
Unicode Point 9089
通常の文字 glyph id = 14243 Unicode Point 909A
通常の文字 glyph id = 14237
IdM の結論
大学における IdM を適切に行なう方法は確立されていない 大学によって IdM の方法は異なる可能性が高い
今後の重要な検討課題であり, 大学間の情報共有が重要