5 년 된 사람에게 "청구서 기반 인증"을 설명

글쎄요, 5 살짜리 아이가 아니라 가능한 한 유행어 나 기업 연설을 피하십시오.

클레임 기반 인증은 현재 모든 분노 인 것처럼 보이지만 실제로는 무엇이고 현재와 어떻게 다른지에 대한 간단하고 실질적인 설명을 찾을 수 없었습니다 ( "현재있는 것"으로 가정) 역할 기반 인증이어야 함), 사용시 이점 등

@Marnix는 꽤 좋은 답변을 제공하지만 기술적 인 측면에서 멀어집니다.

클레임 기반 인증은 신원에 대한 정확한 정보를 제공하고 제공된 정보 만 사용하도록 신뢰하는 사람을 정의하는 것입니다. 나의 (가기) 예제는 술집에 있습니다. 바에서 맥주를 ​​마시고 싶은 순간을 상상해보십시오. 이론적으로 바텐더는 나이의 증거를 요구해야합니다. 그것을 어떻게 증명합니까? 글쎄, 하나의 옵션은 바텐더가 당신을 반으로 자르고 고리 ​​수를 세는 것입니다. 그러나 그것에 약간의 문제가있을 수 있습니다. 다른 옵션은 바텐더가 승인하거나 비 승인 한 종이에 생일을 적는 것입니다. 세 번째 옵션은 정부에 가서 신분증을 발급받은 다음 바텐더에게 신분증을 제시하는 것입니다.

어떤 사람들은 종이에 생일을 쓰는 아이디어에 대해 웃을 수도 있지만, 이는 응용 프로그램 자체 내에서 사용자를 인증 할 때 일어나는 일입니다. . 그러나 ID의 생일이 유효하고 ID는 음료를 요청하는 사람에 대한 정부의 주장을 신뢰합니다. 모든 의도와 목적을 위해 바텐더 (또는 응용 프로그램)는 신뢰로 인해 인증이 어떻게 발생했는지 실제로 신경 쓰지 않습니다. 바텐더는 생년월일을 제외하고는 당신에 대해 아무것도 모른다. 왜냐하면 바텐더가 알아야 할 전부이기 때문이다. 이제 바텐더는 좋아하는 음료와 같이 자신에게 중요하다고 생각하는 정보를 저장할 수 있지만 정부는 신뢰할 수있는 정보가 아니기 때문에 신경 쓰지 않습니다.

CBA의 핵심은 "신원의 권위있는 출처는 누구입니까?"입니다.

(이것은 내 개인적인 취향이며 다른 것은 다를 수 있습니다. 다른 견해를 별도의 답변으로 게시하십시오.)

클레임 기반 자격 증명 / 인증 / 권한 부여는 인증 / 권한을 별도의 (웹) 서비스로 전환하여 (웹) 응용 프로그램에서 사용자 권한 및 사용자 로그인 유지 관리를 분리하는 것입니다.

예를 들어, 클레임 지원 웹 응용 프로그램을 처음 탐색하면 브라우저가 신뢰할 수있는 '로그온 서비스'로 브라우저가 리디렉션됩니다. 해당 서비스를 인증하고 (Windows 인증, 스마트 카드 등) 브라우저가 웹 응용 프로그램으로 다시 보내는 '토큰'을 보냅니다. 이제 웹 응용 프로그램은 신뢰할 수있는 로그온 서비스에 의해 토큰에 디지털 서명이 있는지 확인한 다음 토큰의 '클레임'을 확인합니다. 이러한 주장에 근거하여 응용 프로그램은 사용자에게 제공되는 기능을 결정합니다.

클레임에는 거의 항상 사용자의 신원이 포함되며, 종종 권한 부여 관련 클레임 ( '이 사용자는 영업 데이터를 볼 수 있지만 업데이트하지는 않음')이 있으며 때로는 다른 정보도 있습니다 ( '신발 크기 = 42').

요점은 응용 프로그램이 사용자 인증 방법이나 권한 부여 관리 방법을 알거나 신경 쓰지 않는다는 것입니다. 서명 된 토큰의 클레임 정보 만 사용하여 사용자가 누구인지 및 / 또는 사용자가 무엇을 할 수 있는지 결정합니다. 사용자에 대한 참조 또는 수행 및 / 또는 기타 정보.

(예, 저는 꽤 똑똑하고 정보가 풍부한 5 살짜리 아이를 가정합니다. :-)

다음 실제 사례는 클레임 기반 ID 및 액세스 제어 가이드 (2 판) 에서 발췌 한 것입니다 .

매우 친숙한 비유는 공항 을 방문 할 때마다 따르는 인증 프로토콜 입니다. 게이트까지 걸어 가서 여권이나 운전 면허증을 제시 할 수는 없습니다. 대신, 먼저 티켓 카운터에서 체크인해야합니다. 여기, 자격 증명이 의미가있는 모든 것을 제시합니다. 해외에가는 경우 여권을 제시하십시오. 국내선의 경우 운전 면허증을 제시합니다. 사진 ID가 본인의 얼굴과 일치하는지 확인한 후 ( 인증 ) 상담원이 항공편을 검색하고 항공권 요금을 지불했는지 확인합니다 ( 인증 ). 모든 것이 정돈되어 있다고 가정하면 탑승구로가는 탑승권을받습니다.

탑승권은 매우 유익하다. 게이트 요원은 귀하의 이름과 상용 고객 번호 (인증 및 개인화), 항공편 번호 및 좌석 우선권 (승인) 등을 알고 있습니다. 게이트 에이전트는 작업을 효율적으로 수행하는 데 필요한 모든 것을 갖추고 있습니다.

탑승권에 관한 특별 정보도 있습니다. 뒷면의 바코드 및 / 또는 자기 띠에 인코딩되어 있습니다. 이 정보 (예 : 탑승 일련 번호)는 패스가 항공사에서 발행했으며 위조품이 아님을 증명합니다.

본질적 으로 탑승권은 항공사가 귀하에 대해 서명 한 청구권 집합입니다 . 특정 시간에 특정 항공편에 탑승하고 특정 좌석에 앉을 수 있다고 명시되어 있습니다. 물론 에이전트는 이에 대해 깊이 생각할 필요가 없습니다. 그들은 단순히 탑승권의 유효성을 검사하고 그에 대한 주장을 읽고 비행기에 탑승하게합니다.

또한 탑승권 인 서명 된 클레임 집합을 얻는 방법은 여러 가지가있을 수 있습니다. 공항의 매표소로 가거나 항공사 웹 사이트를 이용하여 집에서 탑승권을 인쇄 할 수 있습니다. 비행기에 탑승 한 게이트 요원은 탑승권이 어떻게 만들어 졌는지 상관하지 않습니다. 항공사가 신뢰하는 한 어떤 발행자를 사용하든 상관 없습니다. 그들은 비행기에 탑승 할 수있는 권한을 부여하는 진정한 주장의 주장 일뿐입니다.

소프트웨어 에서이 클레임 번들을 보안 토큰이라고합니다 . 각 보안 토큰은 토큰 을 만든 발급자 가 서명 합니다. 클레임 기반 응용 프로그램은 신뢰할 수있는 발급자가 서명 한 유효한 보안 토큰을 제시하면 사용자가 인증 된 것으로 간주합니다 .

5 년간 소년의 경우, 부모의 신청서에 서명하여 새 학교에 입학했다고 가정 해보십시오. 학교 경영진의 승인을받은 후 학교에 입국하기 위해 CLAIMS라고하는 아래의 모든 정보가 들어있는 액세스 카드를받습니다.

1. BOY의 이름은 BOB입니다.
2. 학교 이름은 MONTISSORI 고등학교입니다
3. 수업은 8 학년입니다

학교에 들어가는 첫날 학교에 출입 카드를 훔 쳤고 문이 열렸습니다. 이는 학교에서 온 사람 중 한 명으로 청구되었다는 의미입니다. 이런 식으로 그는 학교에 입학 할 수있는 공인 된 사람입니다.

자신의 반에 도달 한 후, 그는 출입 카드를 사용하여 각 반에 들어 갔지만 8 번 표준에서 주장한대로 8 번 표준 클래스 문이 열렸습니다.

학교에서 그는 현재 8 학년을 공부하고있을 때만 수업에 참여할 수 있습니다. 그리고 그가 6th Standard에 들어 가려고한다면, 학교 교사는 그를 인정하지 않을 것입니다.

가능한 비 기술적 :

자신이 누구인지, 무엇을 보거나 할 수 있는지에 대해 무엇이든 설명해야한다면, 그 각각은 사실이라고 "고발"한 것이 될 것입니다. 따라서 그 목록의 각 "것"은 " 청구".

당신이 누군가에게 자신에 대해 말하거나 무언가를 보거나 할 수 있다고 "청구"할 때마다, 당신은 그들에게 당신의 주장 목록을 건네줍니다. 그들은 귀하의 주장이 사실임을 당국에 확인하고, 그 주장이 사실이라면 그 주장의 목록에있는 것을 믿습니다. 따라서 귀하가 Brad Pitt라고 주장하는 경우 귀하의 청구 목록에 귀하가 Brad Pitt라고 주장하고 귀하의 주장이 모두 사실임을 당국이 확인한 경우 귀하가 Brad Pitt와 함께 있다고 믿게됩니다 그 목록의 다른 것.

주장 : 당신이 진실이라고 주장하는 것. 이것은 정보의 일부이거나 귀하가 주장하는 허가에 대한 설명 일 수 있습니다. 귀하가 귀하의 청구를 제시하는 시스템은 그 청구가 무엇인지 / 의미가 무엇인지 이해하고 당국에 확인할 수 있어야합니다.

권한 : 귀하의 청구 목록을 정리하고 기본적으로 "내 권한으로는이 목록의 모든 내용이 사실입니다"라고 서명하는 시스템입니다. 클레임을 읽는 시스템이 서명이 올바른 권한을 가진 기관으로 확인할 수있는 한 클레임 목록의 모든 내용은 진품으로 간주됩니다.

또한 "기반 인증 요구"라고 부르지 말고 대신 "기반 인증 요구"라고하겠습니다.

약간 더 기술적 인 것 :

그래서 지금이 과정에서, 당신은 인증 메커니즘 (사용자 이름 / 암호, 클라이언트 비밀번호, 인증서 등)의 일종을 사용하고 당신이 당신이 말하는 그 누구이며 증명하는 토큰을 제공합니다. 그런 다음 해당 액세스 토큰을 ID 토큰으로 교환합니다. 이 프로세스는 귀하의 신원을 사용하여 클레임 목록을 찾아서 작성하고 서명 한 다음 모든 클레임이있는 ID 토큰을 돌려줍니다.

는 AS 인증 단계가 구현되는 방식에 따라 자원은 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;"}
]

따라서 Jon이 로그인하여 위에서 설명한 리소스에 액세스하려고하면 거부됩니다. 왜냐하면 그가 말한 사람이고 검은성에 액세스 할 수는 있지만 더 이상 주 지휘관이 아니거나 명시 적으로 액세스 할 수 없기 때문입니다. 사령관의 탑으로 암묵적으로 주 지휘관의 탑에 들어갈 수 없습니다.

더 구체적으로 말하면, "CastleBlack"은 아마도 더 큰 범위 일 것이고, 각 영역은 특정한 허가 일 것이지만, 그것은 다른 토론입니다.

각 응용 프로그램이 액세스를 처리하는 방법은 달라 지지만 클레임을 사용하여 액세스합니다.

클레임은 보안 토큰 서비스에 대해 작업하여 해당 클레임을 유효성 검사하고 인증 이외의 권한 부여에 사용하는 사용자 (이름, 연령, 민족성 등)에 대한 정보를 제공하는 특성임을 고려하십시오.

다음 발췌 부분은 Wikipedia ( http://en.wikipedia.org/wiki/Claims-based_identity )와 지금까지 찾은 최고의 비유 에서 발췌 한 것입니다.

"보안 토큰 서비스의 개념을 더 잘 이해하려면, 도어맨과 나이트 클럽의 비유를 고려하십시오. 도어맨은 미성년자 출입을 막고 자합니다.이를 위해 고객에게 운전 면허증, 건강 보험 카드 제시를 요청합니다 또는 주정부 또는 주 차량 면허 부서, 보건 부서 또는 보험 회사와 같은 신뢰할 수있는 제 3 자 (보안 토큰 서비스)가 발급 한 기타 식별 (토큰) 나이트 클럽은 고객의 판단에 대한 책임을 경감합니다. 나이. 발행 기관을 신뢰해야하며 (물론 제시된 토큰의 진위 여부에 대한 자체 판단)이 두 단계가 완료되면 나이트 클럽은 자신의 주장에 대해 고객을 성공적으로 인증했습니다. 법적 음주 연령.

유추를 계속하면 나이트 클럽에는 회원 시스템이있을 수 있으며 특정 회원은 정규 또는 VIP 일 수 있습니다. 도어맨은 다른 토큰, 멤버십 카드를 요청할 수 있습니다. 회원이 VIP임을 이 경우 토큰의 신뢰할 수있는 발급 기관은 아마도 클럽 자체 일 것입니다. 회원 카드가 고객이 VIP라고 주장하는 경우, 클럽은 이에 따라 대응할 수 있으며, 인증 된 VIP 회원 자격을 고객이 독점 라운지 구역에 앉아 무료 음료를 제공하는 것과 같은 허가로 번역 할 수 있습니다. "