[upki-fed:228] Re: [upki-fed:206] Re: UPKIフェデレーションの属性追加について

[Toyokazu Akiyama <xxxxxxx@xxxxxxxxxxxxxxxxxx>]

京産大の秋山です．

# 同じ京産大なのにあんまり議論できてなくてすいません．＞尾崎さん

> (1) 職員番号と学生番号は区別せず、統合された一つの番号系とする。
> （それに職員番号、学生番号などをどう埋め込むかは各大学に任せる）
> (2) 職員番号と学生番号を別々に扱う
> (3) 職員番号、学生番号、それらを統合した番号、の三つの属性を定義しておく

例えば (1) にしようとすると，とりあえず大学ごとに付与ルールは独立している（IDが
重複する可能性がある）ので，IDからユーザを一意に識別しようとすると，大学の
スコープ（@kyoto-su等）は必要だとして，基本的に各大学のシステムで「職員番号」
と「学生番号」は独立に付与されている（管轄部署が学務と人事で異なる）ことを
想定すると，それらが重複していない保証はないので，なんらかの区別が必要では
ないかと思われます．

SP 側でアプリケーションを構築する際にこれらを同じ属性に書かれたIDに対する処理
で区別できた方がロジックとして記述しやすいのであれば，

@faculty.kyoto-su
@student.kyoto-su

のようなスコープを用意することになるのでしょうか．

このようなスコープをアプリケーション（SP）側で他のSAML属性（例えば eduPersonAffiliation）
から取得して付与するのか，ID生成時に付与しておくのかによって，使い勝手は変わってきそうですね．

> 偽IdPに誘導されたら、SSLでないとかよく見ればURLが怪しいとかよく見れば気
> づくはずですが、少なく見積もっても１０人に１人くらいは、悩まず素直にIDと
> パスワードを打ち込んでしますと思います。

偽 IdP 対策としては，PKIに行く前にログインシールを使うという方法もありそうです．

https://protect.login.yahoo.co.jp/

Shibboleth って実装しないんですかね？

-- 
Toyokazu AKIYAMA
Faculty of Computer Science and Engineering,
Kyoto Sangyo University
TEL/FAX: +81-75-705-1531