Jelaskan “otentikasi berbasis klaim” kepada anak berusia 5 tahun

Ya, tidak persis untuk anak berusia 5 tahun, tapi tolong hindari kata kunci dan kata-kata perusahaan jika memungkinkan.

Otentikasi berbasis klaim tampaknya menjadi hal yang populer sekarang, tetapi saya tidak dapat menemukan penjelasan yang sederhana dan sederhana tentang apa sebenarnya itu, bagaimana perbedaannya dari apa yang kita miliki sekarang (saya berasumsi "apa yang kita miliki sekarang" untuk menjadi otentikasi berbasis peran), apa manfaat menggunakannya, dll.

@Marnix memiliki jawaban yang cukup bagus, tetapi untuk menjauh dari aspek teknis:

Otentikasi Berbasis Klaim adalah tentang menentukan siapa yang Anda percayai untuk memberi Anda informasi yang akurat tentang identitas, dan hanya pernah menggunakan informasi yang disediakan. Contoh masuk saya adalah di bar. Bayangkan sejenak bahwa Anda ingin mendapatkan bir di bar. Secara teori bartender harus menanyakan bukti usia. Bagaimana Anda membuktikannya? Nah, salah satu pilihan adalah membuat bartender memotong Anda menjadi dua dan menghitung jumlah dering, tetapi mungkin ada beberapa masalah dengan itu. Pilihan lain adalah bagi Anda untuk menuliskan ulang tahun Anda di selembar kertas yang disetujui atau tidak disetujui oleh bartender. Opsi ketiga adalah pergi ke pemerintah, mendapatkan kartu ID, dan kemudian menunjukkan kartu identitas kepada bartender.

Beberapa orang mungkin menertawakan gagasan hanya menulis ulang tahun Anda di selembar kertas, tetapi inilah yang terjadi ketika Anda mengautentikasi pengguna dalam aplikasi itu sendiri karena terserah kepada bartender (atau aplikasi Anda) untuk mempercayai selembar kertas itu. . Namun, kami percaya pernyataan pemerintah bahwa tanggal lahir pada ID itu valid, dan ID itu untuk orang yang meminta minuman. Untuk semua maksud dan tujuan, bartender (atau aplikasi) tidak terlalu peduli bagaimana otentikasi terjadi karena kepercayaan. Bartender tidak tahu apa-apa tentang Anda kecuali tanggal lahir Anda karena hanya itu yang perlu diketahui oleh bartender. Sekarang, bartender dapat menyimpan informasi yang mereka anggap penting bagi mereka, seperti minuman favorit Anda, tetapi pemerintah tidak peduli (karena itu bukan sumber yang berwenang),

Kunci CBA adalah "siapa sumber identitas yang resmi?"

(Ini pendapat pribadi saya tentang hal ini, orang lain mungkin berbeda. Harap posting sudut pandang lain sebagai jawaban terpisah.)

Identitas / otentikasi / otorisasi berbasis klaim adalah tentang memisahkan pemeliharaan otorisasi pengguna dan pengguna masuk dari aplikasi (web), dengan mengubah otentikasi / otorisasi menjadi layanan (web) terpisah.

Jadi misalnya, ketika saya menjelajah ke aplikasi web yang diaktifkan klaim untuk pertama kalinya, itu akan mengarahkan browser saya ke 'layanan masuk' yang dipercaya. Saya akan mengautentikasi ke layanan itu (menggunakan otentikasi Windows, kartu pintar, atau apa pun), dan sebagai tanggapannya ia mengirimkan kembali 'token', yang dikirimkan browser kembali ke aplikasi web. Sekarang aplikasi web memeriksa bahwa token ditandatangani secara digital oleh layanan masuk yang dipercaya, dan kemudian melihat 'klaim' di token. Berdasarkan murni pada klaim-klaim itu, aplikasi memutuskan fungsionalitas apa yang ditawarkan pengguna.

Klaim akan hampir selalu mencakup identitas pengguna, sering kali ada juga klaim yang terkait dengan otorisasi ('pengguna ini dapat melihat data Penjualan, tetapi tidak memperbaruinya'), dan terkadang informasi lainnya juga ('ukuran sepatu = 42').

Poin kuncinya adalah bahwa aplikasi tidak tahu atau tidak peduli bagaimana pengguna diotentikasi, atau bagaimana otorisasi diadministrasikan: itu hanya menggunakan informasi dari klaim dalam token yang ditandatangani untuk menentukan siapa pengguna itu dan / atau apa yang mungkin pengguna gunakan lihat atau lakukan dan / atau informasi lain tentang pengguna.

(Ya, saya mengasumsikan anak berusia 5 tahun yang cukup cerdas dan berpengetahuan luas di sini. :-)

Contoh dunia nyata berikut diambil dari Panduan untuk Identitas Berbasis Klaim dan Kontrol Akses (Edisi ke-2) .

Analogi yang sangat akrab adalah protokol otentikasi yang Anda ikuti setiap kali Anda mengunjungi bandara . Anda tidak bisa begitu saja berjalan ke pintu gerbang dan menunjukkan paspor atau SIM Anda. Sebagai gantinya, Anda harus check-in terlebih dahulu di konter tiket. Di sini, Anda menyajikan kredensial apa pun yang masuk akal. Jika Anda pergi ke luar negeri, Anda menunjukkan paspor Anda. Untuk penerbangan domestik, Anda menunjukkan SIM Anda. Setelah memverifikasi bahwa ID gambar Anda cocok dengan wajah Anda ( otentikasi ), agen mencari penerbangan Anda dan memverifikasi bahwa Anda telah membayar tiket ( otorisasi ). Dengan asumsi semua sudah beres, Anda menerima boarding pass yang Anda bawa ke gerbang.

Sebuah boarding pass sangat informatif. Agen gerbang mengetahui nama Anda dan nomor frequent flyer (otentikasi dan personalisasi), nomor penerbangan Anda dan prioritas tempat duduk (otorisasi), dan mungkin bahkan lebih. Agen gerbang memiliki segala yang mereka butuhkan untuk melakukan pekerjaan mereka secara efisien.

Ada juga informasi khusus mengenai boarding pass. Itu dikodekan dalam kode batang dan / atau strip magnetik di bagian belakang. Informasi ini (seperti nomor seri boarding) membuktikan bahwa pass dikeluarkan oleh maskapai dan bukan pemalsuan.

Intinya, boarding pass adalah serangkaian klaim yang ditandatangani oleh maskapai tentang Anda . Ini menyatakan bahwa Anda diperbolehkan naik penerbangan tertentu pada waktu tertentu dan duduk di kursi tertentu. Tentu saja, agen tidak perlu terlalu memikirkan hal ini. Mereka hanya memvalidasi boarding pass Anda, membaca klaim di atasnya, dan membiarkan Anda naik pesawat.

Penting juga untuk dicatat bahwa mungkin ada lebih dari satu cara untuk memperoleh set klaim yang ditandatangani yang merupakan boarding pass Anda. Anda mungkin pergi ke konter tiket di bandara, atau Anda dapat menggunakan situs web maskapai dan mencetak boarding pass Anda di rumah. Agen gerbang yang menaiki penerbangan tidak peduli bagaimana boarding pass dibuat; mereka tidak peduli penerbit mana yang Anda gunakan, asalkan dipercaya oleh maskapai. Mereka hanya peduli bahwa itu adalah serangkaian klaim otentik yang memberi Anda izin untuk naik ke pesawat.

Dalam perangkat lunak, bundel klaim ini disebut token keamanan . Setiap token keamanan ditandatangani oleh penerbit yang membuatnya. Aplikasi berbasis klaim menganggap pengguna diautentikasi jika mereka memberikan token keamanan yang sah dan ditandatangani dari penerbit tepercaya .

Untuk anak laki-laki 5 tahun, minta dia untuk berasumsi dia bergabung dengan sekolah baru dengan menandatangani aplikasi oleh orang tuanya. Setelah persetujuan dari manajemen sekolah untuk permohonannya, ia mendapat kartu akses yang berisi semua informasi di bawah ini yang dapat kita sebut KLAIM untuk masuk ke sekolah.

1. NAMA BOY adalah BOB.
2. NAMA SEKOLAH ADALAH SEKOLAH TINGGI MONTISSORI
3. CLASS IS 8TH GRADE

Pada hari pertama sekolahnya ketika dia berjalan ke sekolah, dia menggesek kartu aksesnya dan gerbang dibuka, berarti dia telah DIKLAIM SEBAGAI salah satu orang dari sekolah. Dengan cara ini dia adalah ORANG OTENTIK untuk masuk ke sekolah.

Setelah mencapai kelasnya, ia menggunakan kartu akses untuk masuk ke setiap kelas, tetapi pada pintu Kelas Standar 8 dibuka saat ia Diklaim berasal dari Standar ke-8.

Di sekolah, ia hanya diberi wewenang untuk masuk ke kelasnya karena ia sekarang belajar Standar ke-8. Dan jika dia mencoba untuk masuk ke dalam Standar 6, guru sekolah TIDAK AKAN MENGADILASINYA.

Sebagai non-teknis mungkin:

Jika Anda menggambarkan apa pun tentang siapa Anda dan apa yang diizinkan untuk Anda lihat atau lakukan, masing-masing hal itu akan menjadi sesuatu yang Anda "klaim" sebagai benar, dan dengan demikian setiap "hal" pada daftar itu akan menjadi " klaim".

Setiap kali Anda memberi tahu seseorang tentang diri Anda atau "klaim" bahwa Anda diizinkan melihat atau melakukan sesuatu, Anda menyerahkan daftar klaim itu kepada mereka. Mereka akan memverifikasi dengan otoritas bahwa klaim Anda benar dan jika benar, mereka akan mempercayai apa pun dalam daftar klaim itu. Jadi jika Anda mengklaim bahwa Anda adalah Brad Pitt, daftar klaim Anda mengatakan bahwa Anda adalah Brad Pitt, dan itu diverifikasi dengan otoritas bahwa semua klaim Anda benar - maka mereka akan percaya bahwa Anda adalah Brad Pitt bersama hal lain dalam daftar itu.

Klaim : apa yang Anda klaim benar. Ini bisa berupa informasi atau deskripsi izin yang Anda klaim miliki. Sistem di mana Anda menyajikan klaim Anda hanya perlu memahami apa klaim / artinya dan juga dapat memverifikasi dengan otoritas.

Wewenang : Sistem yang menyatukan daftar klaim Anda dan menandatanganinya yang pada dasarnya mengatakan, "Pada otoritas saya, semua yang ada dalam daftar ini adalah benar." Selama sistem membaca klaim dapat memverifikasi dengan otoritas bahwa tanda tangan itu benar, maka semua yang ada dalam daftar klaim akan dianggap otentik dan benar.

Selain itu, jangan menyebutnya "otentikasi berbasis klaim", alih-alih sebut saja "klaim berdasarkan identitas".

Sedikit lebih teknis:

Jadi sekarang dalam proses ini, Anda mengautentikasi menggunakan semacam mekanisme (nama pengguna / kata sandi, rahasia klien, sertifikat, dll.) Dan itu memberi Anda token yang membuktikan bahwa Anda adalah diri Anda yang sebenarnya. Lalu, Anda menukar token akses itu dengan token ID. Proses itu akan menggunakan identitas Anda untuk menemukan dan membuat daftar klaim, menandatanganinya, dan kemudian memberikan Anda token ID yang memiliki semua klaim Anda.

Sebagai langkah otorisasi , tergantung pada bagaimana penerapannya, sumber daya akan melihat token ID Anda (klaim) dan kemudian memeriksa apakah Anda memiliki klaim yang diperlukan untuk mengakses sumber daya itu.

Jadi misalnya, jika sumber daya "CastleBlack / CommandersTower" mengatakan bahwa "Anda harus memiliki akses ke kastil hitam dan menjadi komandan bangsawan, maka itu akan melihat daftar klaim Anda untuk melihat apakah kedua hal itu benar.

Seperti yang Anda lihat, "klaim" bisa berupa apa saja. Ini bisa menjadi sebuah peran, itu bisa menjadi fakta, itu bisa menjadi sebuah bendera. Itu hanya daftar pasangan nilai kunci dan "nilai" adalah opsional. Terkadang hanya tentang melihat apakah ada klaim:

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;"}
]

Jadi jika Jon masuk dan mencoba mengakses sumber daya yang dijelaskan di atas, dia akan ditolak karena, sementara dia yang dia bilang dia dan dia memiliki akses ke kastil hitam, dia tidak lagi penguasa komandan juga tidak memiliki akses eksplisit ke menara komandan, dan dengan demikian tidak dapat secara implisit memasuki menara komandan tuan.

Lebih khusus, "CastleBlack" mungkin akan menjadi lingkup [lebih besar], dan setiap area akan menjadi izin khusus, tapi itu diskusi yang berbeda.

Bagaimana setiap aplikasi berurusan dengan akses akan berbeda, tetapi akan menggunakan klaim untuk melakukannya.

Menimbang bahwa klaim adalah atribut yang memberi tahu Anda sesuatu tentang pengguna (nama, usia, etnis, dll.) Anda bekerja melawan layanan token keamanan untuk memvalidasi klaim tersebut dan juga menggunakannya untuk otorisasi selain dari otentikasi.

Kutipan berikut diambil dari Wikipedia ( http://en.wikipedia.org/wiki/Claims-based_identity ) dan analogi terbaik yang saya temukan sejauh ini

"Untuk lebih memahami konsep layanan token keamanan, pertimbangkan analogi klub malam dengan penjaga pintu. Penjaga pintu ingin mencegah pengunjung di bawah umur masuk. Untuk memfasilitasi ini, ia meminta pelindung untuk menunjukkan SIM, kartu asuransi kesehatan. atau identifikasi lain (token) yang telah dikeluarkan oleh pihak ketiga yang tepercaya (layanan token keamanan) seperti departemen lisensi provinsi atau kendaraan negara, departemen kesehatan atau perusahaan asuransi. Dengan demikian klub malam dikurangi tanggung jawabnya untuk menentukan pelindung pelanggan. Ini hanya harus memercayai otoritas penerbit (dan tentu saja membuat penilaian sendiri tentang keaslian token yang disajikan). Dengan dua langkah ini selesai, klub malam telah berhasil mengotentikasi pelindung sehubungan dengan klaim bahwa ia berasal dari usia minum yang legal.

Melanjutkan analoginya, kelab malam mungkin memiliki sistem keanggotaan, dan anggota tertentu mungkin biasa atau VIP. Penjaga pintu mungkin meminta token lain, kartu keanggotaan, yang mungkin membuat klaim lain; bahwa anggota adalah seorang VIP. Dalam hal ini otoritas penerbit token yang dipercaya mungkin adalah klub itu sendiri. Jika kartu keanggotaan membuat klaim bahwa pelindungnya adalah VIP, maka klub dapat bereaksi sesuai itu, menerjemahkan klaim keanggotaan VIP yang diautentikasi ke izin seperti pelindung yang diizinkan untuk duduk di area lounge eksklusif dan dilayani minuman gratis. "