識別、認証、認可におけるIdMの役割

たまにはプロダクトの話ではなく、IdMそのものについて書いてみようと思います。

さて、この手のシステムをやっているとお客様を含めついつい混同されがちなのが、識別と認証と認可というキーワードだと思います。そのような混同があるのでIdMツールを入れればシングルサインオンまで含め全部何とかなる、といった勘違いが起きるのだと思います。

そこで、今回は識別、認証、認可といったキーワードの定義とIdMはそれらのキーワードに対して何をしてくれるものなのか？について整理をしてみようと思います。

まずはそれぞれの言葉の定義を見てみましょう。

識別：物事の相違を見分けること
認証：何らかの知識を元に対象の正当性を確認すること
認可：認めて許すこと

たとえば、グリム童話の「7匹の子ヤギ」に当てはめてみましょう。（コンセプトはサルでもわかるIdMの役割！です）

■識別
オオカミ：お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別①

■認証（失敗の例Ⅰ）
子ヤギ　：（本当にお母さんかな？声がおかしいぞ）
　→名乗った名前（お母さん）と声（オオカミの声）という属性を使って正当性を確認
子ヤギ　：お母さんはそんな声じゃない。おまえはお母さんじゃない！
　→認証失敗②

■認証（失敗の例Ⅱ）
オオカミ：（チョークを食べて声を変えて再び）お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
　→ここまでは先ほどと同じ
子ヤギ　：（本当にお母さんかな？声はお母さんの声に似ているな。ん？扉から見える手が黒いぞ。おかしいぞ）
　→名乗った名前（お母さん）と手の色（オオカミの手）という属性を使って正当性を確認
子ヤギ　：お母さんの手はそんな色じゃない。おまえはお母さんじゃない！
　→認証失敗③

■認証（成功の例）
オオカミ：（手に白い粉を塗って）お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
子ヤギ　：（本当にお母さんかな？声はお母さんの声に似ているな。扉から見える手もお母さんの手に似ているな）
　→名乗った名前（お母さん）と手の色（白く塗ったオオカミの手）という属性を使って正当性を確認
子ヤギ　：（確かにお母さんだ）
　→認証成功④

■認可
子ヤギ　：（お母さんは家族だから扉を開けても良いな）お帰りなさい。（扉を開ける）
　→認可⑤


整理すると、
①で対象が与えた情報を元に子ヤギは対象を識別します。
ここで最初から「田中です」と言っても「誰やねん」という話になり子ヤギからは識別されませんので次のフェーズ（認証）へは物事は進みません。

次に②で子ヤギは対象が与えた情報（声）を元に本当に対象があらかじめ与えた識別情報と合致しているかどうかの正当性の検証を行います。
ここでは「声」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。

同様に③では、「声」に加えて対象が与えた情報（手の色）を元に正当性の検証を行います。
ここでも「手の色」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。
ちなみに何故チョークを食べると声が優しくなるのかは不明です。。

続いて、④では対象が与えた「声」と「手の色」の両方が子ヤギの知っている「お母さん」のものと同じであることから子ヤギは対象の正当性を認めます。つまりやっと認証成功です。
いわゆる2要素認証ですね。

最後に、対象が正当に「お母さん」であることが確認されたので、「お母さん」の持つ属性（家族）を見てあらかじめ定義された行為（家に入ること）を許可します。
これが新聞屋だったら例え正当性が確認できても家に入れる、ということはしなかったでしょう。（つまり家族ではないので家に入ることは許可されない）


ちょっと回りくどかったと思いますが、上記が識別、認証、認可の定義です。
さて、やっとIdMの話です。

IdM（狭義のIdM=provisioning/synchronizationを中心としたもの）の役割は、
・管理対象レポジトリのエントリの追加／削除
・管理対象エントリ属性の変更
であると言うことができます。
ここにワークフローやセルフサービスが入ってきたとしてもそれはあくまでプロビジョニングの条件設定や属性変更の一手段にすぎません。

上記の童話に当てはめてみると、
・管理対象レポジトリ　　→　子ヤギの脳
・エントリ　　　　　　　→　知識（お母さんは知っている。田中さんは知らない）
・管理対象エントリ属性　→　お母さんの声は優しい。お母さんの手は白い。お母さんは家族だ。
となります。（なんかグロいですね・・・）

IdMは子ヤギが識別したり認証したり認可をしたりするために必要な情報の提供をしているだけで、実際に識別や認証や認可をしているのは子ヤギそのものなんです。
ですから、IdMシステムの定義をする際は、対象システムがどんな情報をベースに識別し認証し認可するのか、という情報の洗い出しを厳密に行うことが非常に大切です。

この例をベースに考えると、子ヤギ（システム）は、
・名前（お母さん）を識別機能に使う
・声と手の色を認証機能に使う
・続柄（家族）を認可機能に使う
という洗い出しをあらかじめしておいて、IdMシステムに対しては
・名前
・声
・手の色
・続柄
という4つの属性を子ヤギの脳（対象レポジトリ）の中で正しい状態に保つ、ということが求められる機能だ、という定義を行います。


実際は認証連携やシングルサインオンなど、他のシステムが認めたオブジェクトに対して認可を行ったりすることもあり機能の分割がややこしいのですが、よ～く考えると上記の機能分解ができるはずなので、じっくり考えてIdMで管理が必要な属性と同期先となるレポジトリの定義を整理して行きましょう。