[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[upki-fed:224] Re: UPKIフェデレーションの属性追加について
- Subject: [upki-fed:224] Re: UPKIフェデレーションの属性追加について
- Date: Wed, 16 Jun 2010 22:02:25 +0900
- From: Yasuo Okabe <xxxxx@xxxxxxxxxxxxxxx>
岡部@京大です。
一応コメントしておきますと、偽IdPに誘導するにはまず偽SPに誘導すればいい
わけで、これはいろんな方法でできます。
偽IdPに誘導されたら、SSLでないとかよく見ればURLが怪しいとかよく見れば気
づくはずですが、少なく見積もっても10人に1人くらいは、悩まず素直にIDと
パスワードを打ち込んでしますと思います。
ID/パスワードを盗られてしまったらもはや終わりです。先ほどのメールでは一
応SAML暗号のことを書きましたが、そうしたところでアカウントが乗っ取られて
しまっているわけですからほとんど意味がないかもしれません。
Shibbolethに限らずSSO化はリスクを一点に集中してそこを守ろうとする考え
方で、その分最初の認証が肝心の要なのですが、そのことを利用者に理解しても
らい徹底するのは実際には難しいです。UPKIの理想ではそこをPKI化してカバー
することにしていましたが、現実には当面PKIなしのShibbolethでスタートする
ところがほとんどのはずです。電子ジャーナル程度のサービスばかりであればそ
れでもよいのですが、学内での利用などよりセンシティブな個人情報を扱うSPを
導入される場合には、丁寧にリスク分析をされることをお勧めします。
> ああ,なるほど。偽IdPへの誘導も考えられますね。PKIクライアント認証は敷居が
> 高いのでちょっと選択できそうにありません…。
>
> 本学では利用者に説明しやすいので次のような運用を考えています。
> まだフェデレーションに参加していない状態での構築しかテストしていないので
> 本当に実現できるのかわかりませんが,できますよね?
> #やってみろと言われそう…
> これだとDSにアクセスしないので偽IdP対策にもなるかもしれません。
>
> ・学内にフェデレーションに参加したIdPを用意
> ・学内にフェデレーションに参加したポータルSPを用意
> ・ポータルSPにアクセスするとDSではなく,学内IdPにリダイレクトする
> ・学内IdPで認証されるとポータルSPの画面が表示される
> ・そこに利用できる各SPのリンク集を置いておき,再認証なしに飛べる
>
> #なんだか本題から外れてしまいました。
--
Yasuo Okabe
Kyoto University
http://www.net.ist.i.kyoto-u.ac.jp