考えを整理するためのメモ。たぶん、誰かがもっと洗練した形で考えて、発表していると思う。
既に整理されていた。いろいろ不正確なことを書いていたので以下全面改稿。
用語の整理
私なりの理解では以下のとおり。
| 用語 | 対応する日本語 | 用語の意味 | |||
| identifier（ID） | 識別子 | ある利用者を特定するために用いる情報 | |||
| identity | ? | 利用者を特徴付ける、あらゆる情報 | |||
| certification | 認証 | 信頼できる機関によって、個人やサーバーの実在を保証する証明書を発行してもらうこと | |||
| authentication | 認証、本人認証 | ある識別子について、自分のものだと主張する利用者が本当にその識別子の持ち主であるのかを確認すること | |||
| identification | 識別 | 本人認証の過程の一つ。利用者に識別子を入力してもらうこと | |||
| verification | 検証 | 本人認証の過程の一つ。利用者に識別子保有者であることを証明するデータを入力してもらい、システム内に格納されているデータと照合すること | |||
| authorization | 認可 | 本人認証された識別子を受け入れ、サービスに対して適切な権限を与えること | |||
| accounting | 課金記録 | アクセス＆操作ログを記録すること | |||
| attribute exchange | 属性交換 | あるサービスが、ほかのサービスに対し、特定のユーザーにひも付けられた属性情報を提供すること |
通常のAAAの場合は
- authentication
- identification
- verification
- authorization
- accounting
ID管理（@IT：アイデンティティ管理の新しい教科書）の場合は
- authentication
- identification
- verification
- authorization
- attribute exchange
シングル・サインオン
シングル・サインオンより転載
サービスを提供するサーバが複数存在し、それらがネットワーク上で分散している場合でも、認証を集中的に行うサーバでいったんユーザー認証を受ければ、ユーザー認証を前提としたあらゆるサービスを受けられるようにするしくみ、またはそのような集中的な認証が可能になっている状態。頭文字をとってSSOと呼ばれる場合もある。
ブラウザベースの認証APIは、シングル・サインオンの実現方法の一つ。@IT：OpenIDの仕様と技術 第1回 仕様から学ぶOpenIDのキホンによれば、以下のようなブラウザベースの認証APIがある。
ところが、@IT：アイデンティティ管理の新しい教科書 第1回 「アイデンティティ管理」の周辺事情を整理しようによると、以下のように状況が推移しているらしい。
これら、ID管理に関する技術標準の普及以前にはブラウザベースの認証APIが乱立していた時期もありましたが、現在はOpenID、SAMLのいずれかの方式に収束する方向で推移しています。特に、グローバルな動きではFacebookがOpenIDを採用したことで、「独自認証API vs. ID連携技術標準」の構図に終止符が打たれた感はあります。
このエントリーを書き直す前は、「OpenID＝Webアプリケーションにおけるシングル・サインオンの仕組みの総称」と勘違いしていたので、へんてこなことを書いてしまった。
実存する個人と識別子の関係
Webアプリケーションにおける authentication は「ある識別子について、自分のものだと主張する利用者が本当にその識別子の持ち主であるのかを確認すること」なので、本当に利用者がWebアプリケーション側に申告しているとおりの人間であるかどうかを保証しない。
たとえば、Webアプリケーションを用いて、買い物や賭博、投票や試験を受ける場合には、本当に利用者がWebアプリケーション側に申告しているとおりの人間であるかどうかはとても重要になる。
@IT：OpenIDの仕様と技術によれば、OpenIDの仕様では本当に利用者がWebアプリケーション側に申告しているとおりの人間であるかどうかは、利用者と認証担当サーバの間の問題であり、OpenIDの仕様自体ではこの点を保証しない。
本当に利用者がWebアプリケーション側に申告しているとおりの人間であるかどうかのcertificationは、認証担当サーバーの運用者が行なうこと。
識別子と集団、役割、資源の関係
シングル・サインオンの話を離れて、あるWebアプリケーションにおける識別子、集団、役割、資源の関係を考える。
識別子はあるWebアプリケーション上における1人の利用者を表す。複数人の利用者が集まったものが集団、Webアプリケーションが提供するサービスやそのアプリケーションが管理しているデータが資源、資源をどのように扱うことができるのかが役割。
あるWebアプリケーション上に1つの集団しかない場合は、ある利用者は役割を1つだけ持つ。あるWebアプリケーション上に複数の集団があり、利用者は複数の集団に属せるとき、ある利用者は、集団ごとに異なる役割を持つ場合がある。
アカウント作成時の識別子とパスワードの生成およびその通知方法
よくあるWebアプリケーションにおいて、アカウント作成時の識別子とパスワードの生成および通知方法のパターンの種類は以下のものを組み合わせた結果。
- 本人認証を自分で行なうかどうか：行なう、行なわない（シングル・サインオンを用いる）
- ログイン時に使用する識別子の発行は誰が行なうか：アプリケーション、利用者、本人認証サーバ
- ログイン時に使用するパスワードの発行は誰が行なうか：アプリケーション、利用者、本人認証サーバ
- アカウント作成申請者が人間であることをどうやって確認するか：確認しない、キャプチャを用いる、メールを用いる
- IDとパスワードの通知方法：Webページに表示、メールで通知、両方
おわりに
なんで、これを書き始めたかというとRuby on Railsで使う認証プラグインのうち、自分が作りたいサービスに適したものが分からなかったため。これを書いてだいぶ頭が整理された。
