「クレームベース認証」を5歳の子供に説明する
まあ、正確には5歳ではありませんが、可能であれば流行語や企業の発言は避けてください。
クレームベースの認証は今では大流行しているようですが、実際に何であるか、現在のものとどのように違うのかについての簡単で現実的な説明を見つけることができませんでした役割ベースの認証になります）、それを使用することの利点など.
@Marnixにはかなり良い答えがありますが、技術的な側面から離れるには：
クレームベース認証は、身元に関する正確な情報を提供するために信頼できる人を定義し、提供された情報のみを使用することです。私（の）の例はバーにあります。バーでビールを飲みたいと思うと想像してみてください。理論的には、バーテンダーは年齢の証明をあなたに尋ねるべきです。どうやって証明しますか？さて、1つのオプションは、バーテンダーにあなたを半分にカットして、リングの数を数えることですが、それにはいくつかの問題があるかもしれません。もう1つのオプションは、バーテンダーが承認または不承認にする紙に誕生日を書き留めることです。 3番目のオプションは、政府に行き、IDカードを取得し、IDをバーテンダーに提示することです。
誕生日を紙に書くだけのアイデアを笑う人もいるかもしれませんが、紙自体を信頼するのはバーテンダー（またはアプリケーション）次第であるため、アプリケーション自体でユーザーを認証しているときにこれが起こります。 。ただし、IDの誕生日は有効であり、IDは飲み物をリクエストした人のものであるという政府の主張を信頼しています。すべての意図と目的のために、バーテンダー（またはアプリケーション）は、信頼のために認証がどのように発生したかを実際に気にしません。それはバーテンダーが知る必要があるので、バーテンダーはあなたの生年月日を除いてあなたについて何も知りません。今、バーテンダーはあなたの好きな飲み物のように彼らにとって重要だと思う情報を保存することができますが、政府は（権威あるソースではないので）気にしませんので、バーテンダーはその情報を自分の方法で保存します。
CBAの鍵は「アイデンティティの信頼できるソースはだれですか」です。
（これは私の個人的な見解です。他の人は異なる場合があります。他の視点を別の回答として投稿してください。）
クレームベースのID /認証/承認とは、認証/承認を別の（Web）サービスに変えることにより、ユーザー承認の維持と（Web）アプリケーションからのユーザーサインインを分離することです。
したがって、たとえば、クレーム対応のWebアプリケーションを初めて参照すると、ブラウザーは信頼する「ログオンサービス」にリダイレクトされます。 （Windows認証、スマートカードなどを使用して）そのサービスに対して認証を行い、それに応答して 'トークン'を送り返し、ブラウザはそれをWebアプリケーションに送り返します。これで、Webアプリケーションは、トークンが信頼できるログオンサービスによってデジタル署名されていることを確認し、トークン内の「クレーム」を確認します。純粋にそれらの主張に基づいて、アプリケーションはユーザーに提供される機能を決定します。
クレームにはほとんど常にユーザーのIDが含まれ、多くの場合、承認に関連するクレーム（「このユーザーは販売データを表示できますが、更新はできません」）、およびその他の情報も含まれます（「靴のサイズ= 42」）。
重要な点は、アプリケーションがユーザーの認証方法や承認の管理方法を知らず、気にもしないことです。署名済みトークンのクレームの情報のみを使用して、ユーザーが誰であるか、ユーザーが何であるかを判断しますユーザーに関するその他の情報を表示または実行します。
（はい、私はかなり知性があり、十分な情報に基づいた5歳をここで想定しています。：-）
次の実世界の例は、 クレームベースのIDおよびアクセス制御（第2版）のガイド から引用しています。
非常によく知られている例えは、空港にアクセスするたびに従う認証プロトコルです。単純にゲートまで歩いてパスポートまたは運転免許証を提示することはできません。代わりに、最初にチケットカウンターでチェックインする必要があります。ここでは、意味のある資格情報を提示します。海外に行く場合は、パスポートを提示します。国内線の場合、運転免許証を提示します。写真IDが顔と一致することを確認した後（認証）、エージェントはフライトを検索し、チケットの代金を支払ったことを確認します（承認）。すべてが正常であると仮定すると、搭乗券を受け取ります。
搭乗券は非常に有益です。ゲートエージェントは、名前とフリークエントフライヤー番号（認証とパーソナライゼーション）、フライト番号と座席の優先順位（認可）などを知っています。ゲートエージェントには、仕事を効率的に行うために必要なものがすべて揃っています。
搭乗券に関する特別な情報もあります。バーコードおよび/または背面の磁気ストリップにエンコードされています。この情報（搭乗シリアル番号など）は、パスが航空会社によって発行されたものであり、偽造ではないことを証明しています。
本質的に、搭乗券は航空会社があなたについて行った署名付きの一連の申し立てです。特定の時間に特定のフライトに搭乗し、特定の座席に座ることが許可されていることが記載されています。もちろん、エージェントはこれについて深く考える必要はありません。彼らはあなたの搭乗券を検証し、その請求を読み、飛行機に搭乗させます。
また、搭乗券である署名入りのクレームを取得する方法は複数ある場合があることに注意することも重要です。空港のチケットカウンターに行くか、航空会社のWebサイトを使用して自宅で搭乗券を印刷します。フライトに搭乗するゲートエージェントは、搭乗券の作成方法を気にしません。航空会社から信頼されている限り、どの発行者を使用したかは関係ありません。彼らは、それが飛行機に乗る許可をあなたに与える本物の主張のセットであることにのみ気をつけています。
ソフトウェアでは、このクレームのバンドルはセキュリティトークンと呼ばれます。各セキュリティトークンは発行者によって署名された作成者です。 クレームベースのアプリケーションは、信頼できる発行者からの有効な署名済みセキュリティトークンを提示した場合、ユーザーは認証されたと見なします。
5歳の少年の場合、両親が申請書に署名することで、新しい学校に入学したと仮定するように頼みます。学校管理者からの申請の承認後、彼は学校に入学するためにクレームと呼ぶことができる以下のすべての情報を含むアクセスカードを取得します。
- ボーイの名前はボブです。
- 学校名IS MONTISSORI HIGH SCHOOL
- クラスIS 8年生
学校に入学した初日、彼はアクセスカードをスワイプしてゲートを開き、学校の人の一人として訴えられたことを意味します。このように、彼は学校に入学する権限のある人です。
クラスに到達した後、彼はアクセスカードを使用して各クラスに参加しましたが、8番目の標準から来たと主張して8番目の標準クラスのドアが開きました。
学校では、彼は現在8番目の標準を勉強しているため、クラスに入ることを許可されているだけです。そして、彼が第6基準に入ろうとすると、学校の先生は彼を認可しません。
可能な限り非技術的：
自分が誰であるか、何を表示または実行できるかについて何かを説明する場合、それらのそれぞれは、あなたが真実であると「主張」しているものであり、したがって、そのリストの各「もの」は「請求"。
誰かに自分自身について何かを言ったり、何かを見たり行動したりすることを「主張」するときはいつでも、あなたに彼らの主張のリストを渡します。彼らはあなたの主張が真実であることを当局に確認し、もしそうなら、彼らはその主張のリストにあるものを信じます。あなたがブラッド・ピットであると主張する場合、あなたの主張のリストはあなたがブラッド・ピットであると言い、あなたの主張がすべて真実であるという権限で検証されました-そして彼らはあなたがブラッド・ピットであると信じますそのリストの他のもの。
申し立て：あなたが真実だと主張するもの。これは、あなたが所有していると主張している許可の説明または説明です。あなたがあなたの主張を提示するシステムは、その主張が何であるか/意味するものを理解するだけでなく、当局で検証できる必要があります。
Authority：クレームのリストをまとめて署名するシステムは、基本的に「私の権限では、このリストのすべてが正しい」と言っています。クレームを読み取るシステムが、署名が正しいことを当局で検証できる限り、クレームのリスト内のすべてが本物で真であると見なされます。
また、「要求ベースの認証」とは呼ばず、代わりに「要求ベースのID」と呼びましょう。
やや技術的な：
したがって、このプロセスでは、何らかのメカニズム（ユーザー名/パスワード、クライアントシークレット、証明書など）を使用してauthenticateトークンを取得します。それは、あなたがあなたがあなたが言っている人であることを証明します。次に、そのアクセストークンをIDトークンに交換します。そのプロセスでは、IDを使用してクレームのリストを見つけて作成し、署名してから、すべてのクレームを含むIDトークンを返します。
authorizationステップとして、実装方法に応じて、リソースはIDトークン（クレーム）を調べ、必要なクレームがあるかどうかを確認しますそのリソースにアクセスします。
たとえば、「CastleBlack/CommandersTower」というリソースが「黒の城にアクセスし、司令官になる必要がある」と言っている場合、クレームのリストを見て、これらの両方が当てはまるかどうかを確認します。
ご覧のとおり、「クレーム」は何でも構いません。それは役割でも、事実でも、フラグでもかまいません。これは単にキーと値のペアのリストであり、「値」はオプションです。クレームが存在するかどうかを確認するだけの場合もあります。
claims : [
{"type": "name", "value": "Jon Snow"},
{"type": "home", "value": "Winterfell, The North, Westeros"},
{"type": "email", "value": "[email protected]"},
{"type": "role", "value": "veteran;deserter;"},
{"type": "department", "value": "none"},
{"type": "allowEntry", "value": "true"},
{"type": "access", "value": "castleblack;eastwatch;"}
]
したがって、Jonがログインして上記のリソースにアクセスしようとすると、彼は拒否されます。なぜなら、彼は自分がそうであり、黒の城へのアクセス権を持っているが、主将ではなく、明示的なアクセス権も持っていないからです指揮官の塔であるため、暗黙のうちに指揮官の塔に入ることはできません。
より具体的には、「CastleBlack」はおそらく[より大きな]スコープであり、各領域は特定の許可になりますが、それは異なる議論です。
各アプリケーションがアクセスを処理する方法は異なりますが、それを行うにはクレームを使用します。
クレームは、セキュリティトークンサービスに対して作業してユーザーに関する情報（名前、年齢、民族など）を伝える属性であり、それらのクレームを検証し、認証以外の承認にも使用することを考慮してください。
次の抜粋は、ウィキペディア（ http://en.wikipedia.org/wiki/Claims-based_identity ）から抜粋したもので、これまでに見つけた最高のアナロジーです
「セキュリティトークンサービスの概念をよりよく理解するには、ナイトクラブとドアマンの例えを考えてください。ドアマンは、未成年の利用者が入場できないようにしたいと考えています。または、州または州の車両免許部門、保健部門、保険会社などの信頼できる第三者（セキュリティトークンサービス）によって発行されたその他のID（トークン）です。したがって、ナイトクラブは、利用者を決定する責任を軽減されます。発行機関のみを信頼する必要があります（もちろん、提示されたトークンの信頼性について独自の判断を下す必要があります）。これらの2つの手順が完了すると、ナイトクラブは、彼または彼女が法定飲酒年齢。
類推を続けると、ナイトクラブには会員制があり、特定の会員は正会員またはVIPである場合があります。ドアマンは別のトークンである会員カードを要求するかもしれません。メンバーがVIPであること。この場合、トークンの信頼できる発行機関はおそらくクラブ自体でしょう。会員カードが利用者がVIPであると主張する場合、クラブはそれに応じて反応し、認証済みVIPラウンジエリアと無料のドリンクを提供します。」