「クレームベースの認証」について5歳の人に説明する

まあ、厳密には5歳ではありませんが、可能であれば流行語や企業の発言は避けてください。

クレームベースの認証は今では大流行しているようですが、実際の内容、つまり現在のものとどのように異なるのかについてのシンプルで現実的な説明は見つかりませんでした（「今あるもの」を想定しています）。役割ベースの認証であること）、それを使用する利点など

@Marnixはかなり良い答えを持っていますが、技術的な側面から離れる必要があります。

クレームベース認証は、IDに関する正確な情報を提供するために信頼できる人物を定義することであり、提供された情報のみを使用します。私の（その）頼りになる例はバーにあります。ちょっとの間、バーでビールを飲みたいと想像してみてください。理論的には、バーテンダーは年齢の証明を求めなければなりません。どうやってそれを証明しますか？まあ、1つのオプションは、バーテンダーがあなたを半分にカットしてリングの数を数えるようにすることですが、それにはいくつかの問題があるかもしれません。もう1つのオプションは、バーテンダーが承認または不承認とする紙に誕生日を書き込むことです。3番目のオプションは、政府に行ってIDカードを取得し、IDをバーテンダーに提示することです。

一枚の紙に誕生日を書くだけだと笑う人もいますが、これは、紙を信頼するのはバーテンダー（またはアプリケーション）に任されているため、アプリケーション自体の中でユーザーを認証しているときに起こります。 。ただし、IDの誕生日は有効であり、IDはドリンクを要求する人のIDであるという政府の主張を信頼しています。すべての意図と目的のために、バーテンダー（またはアプリケーション）は、信頼のために認証がどのように発生したかを気にしません。バーテンダーが知る必要があるのはそれだけなので、バーテンダーはあなたの生年月日以外は何も知りません。これで、バーテンダーは、お気に入りの飲み物のように、彼らにとって重要だと思う情報を保存できますが、政府は気にしません（信頼できる情報源ではないため）。

CBAの鍵は、「アイデンティティの信頼できるソースは誰ですか」です。

（これは私の個人的な見解であり、他のものは異なる場合があります。別の答えとして他の視点を投稿してください。）

クレームベースのID /認証/承認は、認証/承認を別の（Web）サービスに変えることにより、（Web）アプリケーションからユーザー承認とユーザーサインインのメンテナンスを分離することです。

したがって、たとえば、クレーム対応のWebアプリケーションを初めて参照すると、ブラウザが信頼する「ログオンサービス」にリダイレクトされます。そのサービスに対して認証を行い（Windows認証、スマートカードなどを使用）、それに応じて「トークン」を返します。このトークンは、ブラウザーがWebアプリケーションに送り返します。これで、Webアプリケーションは、トークンが信頼できるログオンサービスによってデジタル署名されていることを確認し、トークンの「クレーム」を確認します。これらの主張に純粋に基づいて、アプリケーションはユーザーに提供する機能を決定します。

クレームには、ほとんどの場合、ユーザーのIDが含まれます。多くの場合、承認関連のクレーム（「このユーザーは販売データを表示できますが、更新はできません」）と他の情報も含まれます（「靴のサイズ= 42」）。

重要な点は、アプリケーションはユーザーがどのように認証されたのか、承認がどのように管理されたのかを知らず、気にしないことです。署名されたトークン内のクレームからの情報を使用して、ユーザーが誰であるか、ユーザーが何であるかを判断するだけです。ユーザーに関するその他の情報を表示または実行します。

（はい、私はここでかなりインテリジェントで十分な情報を得ている5歳を想定しています。:-)

次の実際の例は、クレームベースのIDおよびアクセス制御のガイド（第2版）からの抜粋です。

よく知られている例えは、空港に行くたびに使用する認証プロトコルです。単にゲートまで歩いてパスポートや運転免許証を提示することはできません。代わりに、まずチケットカウンターでチェックインする必要があります。ここでは、意味のある資格を提示します。海外に行く場合はパスポートを提示してください。国内線の場合、運転免許証を提示します。写真IDが顔と一致していることを確認した後（認証）、エージェントはフライトを検索して、チケットの代金が支払われたことを確認します（認証）。すべてが順調であると仮定すると、搭乗券を受け取り、ゲートに向かいます。

搭乗券は非常に有益です。ゲートエージェントは、あなたの名前とマイレージ会員番号（認証と個人化）、フライト番号と座席の優先順位（認証）、そしておそらくそれ以上を知っています。ゲートエージェントには、仕事を効率的に行うために必要なものがすべて揃っています。

搭乗券に関する特別な情報もあります。バーコードおよび/または背面の磁気ストリップにエンコードされています。この情報（搭乗のシリアル番号など）は、パスが航空会社によって発行されたものであり、偽造ではないことを証明します。

本質的に、搭乗券は、航空会社があなたについて行った署名付きのクレームセットです。特定の時間に特定のフライトに搭乗し、特定の座席に座ることが許可されていることを示しています。もちろん、エージェントはこれについて深く考える必要はありません。彼らはあなたの搭乗券を検証し、その主張を読み、飛行機に搭乗させるだけです。

また、搭乗券である署名済みのクレームセットを取得する方法は複数ある場合があることに注意することも重要です。空港のチケットカウンターに行くか、航空会社のWebサイトを使用して自宅で搭乗券を印刷します。フライトに搭乗するゲートエージェントは、搭乗券の作成方法を気にしません。航空会社から信頼されている限り、どの発行者を使用してもかまいません。彼らはあなたが飛行機に乗る許可を与えるのが本物の一連の主張であることを気にしているだけです。

ソフトウェアでは、この一連のクレームはセキュリティトークンと呼ばれます。各セキュリティトークンは、それを作成した発行者によって署名されます。クレームベースのアプリケーションは、信頼できる発行者からの有効な署名付きセキュリティトークンを提示した場合、ユーザーが認証されたと見なします。

5歳の男の子の場合は、両親が申請書に署名することにより、彼が新しい学校に入学したと想定するように依頼します。学校の管理者からの申請の承認後、彼は以下のすべての情報を含むアクセスカードを取得します。この情報は、学校に入学するための請求と呼ぶことができます。

1. BOYの名前はBOBです。
2. 学校名はモンティッソリ高校
3. クラスは8番目のグレードです

彼が学校に入る間、彼の学校の最初の日、彼は彼のアクセスカードをスワイプして、門が開いた、それは彼が学校の人の一人として請求されたことを意味します。このように、彼は学校に入学するための認証された人です。

彼のクラスに到達した後、彼は各クラスに入るのにアクセスカードを使用しましたが、8番目の標準では、8番目の標準からであると主張したようにドアが開きました。

学校では、現在第8基準を勉強しているため、クラスに参加することを許可されているだけです。そして、彼が第6基準を入力しようとした場合、学校の先生は彼を許可しません。

できるだけ技術的ではない：

あなたが誰であるか、あなたが見たり、やったりすることを許可されたものについて何かを説明するとしたら、それらのことのそれぞれは、あなたが真実であると「主張する」ものであり、したがって、そのリストの各「もの」は「請求"。

あなたが誰かにあなた自身について何かを伝えたり、あなたが何かを見たりしたりすることを許可されていることを「主張」するときはいつでも、あなたは彼らにあなたの主張のリストを渡してください。彼らはあなたの主張が真実であることを当局に確認し、真実である場合、彼らはその主張のリストにあるものを信じます。したがって、あなたがブラッド・ピットであると主張する場合、あなたの主張のリストはあなたがブラッド・ピットであると述べており、あなたの主張がすべて真実であるという権限で確認されました-そして彼らはあなたがブラッド・ピットであると信じていますそのリストの他の何か。

主張：あなたが真実であると主張するもの。これは、あなたが持っていると主張している許可の一部または情報です。クレームを提示するシステムは、クレームが何であるか/意味を理解し、権限で確認できる必要があります。

権限：クレームのリストをまとめて署名するシステムで、基本的に「私の権限では、このリストのすべてが真実である」と述べています。クレームを読み取るシステムが、署名が正しいことを権限で確認できる限り、クレームのリスト内のすべてが信頼でき、真実であると見なされます。

また、「クレームベースの認証」ではなく、「クレームベースのアイデンティティ」と呼びましょう。

もう少し技術的：

したがって、このプロセスでは、なんらかのメカニズム（ユーザー名/パスワード、クライアントシークレット、証明書など）を使用して認証します。これにより、本人であることを証明するトークンが提供されます。次に、そのアクセストークンをIDトークンと交換します。このプロセスでは、IDを使用してクレームのリストを見つけて作成し、署名してから、すべてのクレームが含まれるIDトークンを返します。

承認手順として、実装方法に応じて、リソースはIDトークン（クレーム）を調べ、そのリソースにアクセスするために必要なクレームがあるかどうかを確認します。

したがって、たとえば、リソース「CastleBlack / CommandersTower」が「城の黒にアクセスでき、指揮官になる必要がある」と言った場合、クレームのリストを見て、これらの両方が真であるかどうかを確認します。

ご覧のとおり、「クレーム」は何でもかまいません。それは役割であったり、事実であったり、旗であったりします。これはキーと値のペアの単なるリストであり、「値」はオプションです。主張が存在するかどうかを確認するだけの場合もあります。

claims : [
    {"type": "name", "value": "Jon Snow"},
    {"type": "home", "value": "Winterfell, The North, Westeros"},   
    {"type": "email", "value": "jon@nightswatch-veterans.org"},
    {"type": "role", "value": "veteran;deserter;"},
    {"type": "department", "value": "none"},    
    {"type": "allowEntry", "value": "true"},
    {"type": "access", "value": "castleblack;eastwatch;"}
]

したがって、ジョンがログインして上記のリソースにアクセスしようとすると、彼は拒否されます。なぜなら、彼は自分が言っているとおりの人物であり、黒の城へのアクセス権は持っているが、主将ではなく、明示的なアクセス権がないためです。司令官の塔、したがって、暗示的に主司令官の塔に入ることはできません。

より具体的には、「CastleBlack」はおそらく[より大きな]スコープであり、各領域は特定の許可ですが、それは別の議論です。

各アプリケーションがアクセスを処理する方法は異なりますが、クレームを使用してアクセスします。

クレームは、ユーザーに関する情報（名前、年齢、民族など）を伝える属性であることを考えると、セキュリティトークンサービスに対してこれらのクレームを検証し、認証とは別に承認に使用します。

次の抜粋はWikipedia（http://en.wikipedia.org/wiki/Claims-based_identity）からの抜粋であり、これは私がこれまでに見つけた最高の類推です

「セキュリティトークンサービスの概念をよりよく理解するには、ドアマンとナイトクラブの類似を考えてください。ドアマンは未成年の常連客の入場を防ぎたいと思っています。これを容易にするために、運転免許証、健康保険証を提示するように常連客に要求します。または、州または州の自動車免許部門、健康部門、保険会社などの信頼できるサードパーティ（セキュリティトークンサービス）によって発行されたその他の識別（トークン）。ナイトクラブは、このようにして、常連客の責任を決定する責任が軽減されます。これは、発行機関を信頼するだけで済みます（もちろん、提示されたトークンの信頼性を独自に判断します）。これらの2つのステップが完了すると、ナイトクラブは、彼または彼女が法定飲酒年齢。

類推を続けると、ナイトクラブにはメンバーシップシステムがあり、特定のメンバーは正規またはVIPである場合があります。ドアマンは別のトークンである会員証を要求するかもしれませんが、これは別の主張をするかもしれません。メンバーがVIPであること。この場合、トークンの信頼できる発行機関はおそらくクラブ自体です。会員証が常連客がVIPであると主張する場合、クラブはそれに応じて対応し、認証されたVIP会員権の主張を、常連客が専用ラウンジエリアに座って無料のドリンクを提供できるなどの許可に変換します。」