Dan kemudian kembali, tidak di Yunani, kita akan membahas pada gambaran tingkat tinggi tentang salmon.
Jadi Salmon adalah singkatan dari bahasa markup Asosiasi Keamanan dan merupakan mekanisme komunikasi berbasis
XML yang aman untuk mengkomunikasikan identitas di seluruh organisasi.
Sekarang, poin ini akan lebih baik dipahami sebentar lagi di sini.
Jadi salmon menghilangkan kebutuhan untuk mempertahankan beberapa kredensial otentikasi, seperti kata sandi di
beberapa lokasi.
Jadi, jika Anda melihat cara klasik di mana Anda memiliki beberapa aplikasi dan layanan yang
berjalan di dalam organisasi Anda dan setiap aplikasi memiliki identitasnya sendiri.
Jadi Jenkins memiliki nama pengguna dan kata sandinya sendiri.
Editor memiliki nama pengguna dan kata sandinya sendiri dalam bentuk H. R. perangkat lunak manajemen akan memiliki nama pengguna dan
kata sandinya sendiri dan seterusnya.
Jadi memiliki ini sedikit menyakitkan.
Jadi mari kita lihat beberapa tantangan dengan cara klasik yang telah kita diskusikan.
Yang pertama adalah bahwa administrator tidak benar-benar memiliki visibilitas dengan database yang mendasari
penyedia SAS.
Jadi saat ini kami sedang membahas tentang JENKINS'.
Jadi, jika Anda meng-hosting Jenkins di dalam layanan Anda sendiri, maka Anda memiliki visibilitas yang baik.
Tetapi ada banyak penyedia layanan yang tidak benar-benar memberi Anda visibilitas database.
Dan faktanya, telah terlihat bahwa banyak tempat di mana nama pengguna dan
kata sandi disimpan mendasari penyimpanannya dalam teks biasa dan bahkan organisasi besar terlibat di sini.
Jadi ini salah satu tantangan besar.
Tantangan kedua adalah jika ada banyak penyedia SaaS, sulit untuk melacak pengguna mana yang
memiliki akses ke aplikasi SaaS mana.
Jadi mungkin saja pengembang memiliki akses ke file Jenkins.
Namun, pengembang, Steve, memiliki akses ke database dan semua pengguna memiliki akses ke database tersebut.
Jadi pada akhirnya, jika pengguna tertentu keluar dari organisasi, sulit untuk mengetahui bahwa pengguna tersebut memiliki akses ke
aplikasi ini, khususnya jika Anda mungkin memiliki aplikasi di dalam organisasi Anda.
Dan itulah poin ketiga, bahwa ketika pengguna meninggalkan organisasi, dia harus dikeluarkan
dari semua entitas.
Itu bisa Jenkins, ET, dll. dan seterusnya.
Jadi saya masih ingat bahwa di organisasi tempat saya bekerja sehingga setiap pengguna
yang meninggalkan organisasi di hari terakhirnya akan datang dengan formulir dan dia memerlukan tanda tangan otoritas.
Jadi, misalnya, dia memiliki akses ke VPN dan dia datang ke tim kami dan kami menghapus aksesnya dan kemudian kami
menandatanganinya di dokumen, yang harus dia serahkan ke API.
Jadi dalam kasus seperti itu, dia harus mengambil tanda tangan dari semua orang yang mengatakan bahwa pengguna dan aksesnya
dihapus dan Post akan mengirimkan formulir itu ke ATO.
Jadi di organisasi yang tidak benar-benar memiliki akses tunggal untuk melakukan hal-hal seperti itu agak merepotkan karena sekarang
Anda harus menghapus aksesnya secara manual dari semua aplikasi.
Jadi mari kita lihat pandangan yang berbeda di sini dalam pendekatan klasik.
Jadi pandangan administrator dalam pendekatan klasik di sini adalah bahwa dia harus masuk ke penyedia
yang berbeda untuk mengelola dan mengontrol izin pengguna individu di seluruh organisasi.
Dan jika dia lupa nama pengguna dan kata sandinya dan mungkin kehilangan yang ini untuk
Amethi, maka administrator harus menyetel MFA baru di semua aplikasi.
Jadi ini sedikit menyakitkan.
Kedua adalah bahwa pengguna melihat tampilan pengguna adalah bahwa dia harus mengingat kata sandi semua aplikasi
dalam organisasi.
Dan mungkin juga ada bahwa penggunaan ide pengguna di seluruh aplikasi berbeda.
Jadi ini lebih terbuka dan pandangan situs lebih luas jika penyedia layanan, jika menyimpan nama pengguna
dan kata sandi, penyedia layanan harus menjaga database nama pengguna dan kata sandi
pelanggan mereka.
Dan jika database ini bocor, maka itu adalah tanggung jawab keamanan yang besar dari aspirator ini.
Jadi dalam tampilan klasik, administrator, pengguna, serta Florida Selatan, semua orang tidak senang.
Jadi sekarang datang cara yang lebih baik, yang sama.
Jadi secara ringkas, apa yang Anda miliki, Anda memiliki penyedia identitas dan Anda memiliki penyedia layanan, Banzet.
Jadi service providernya bisa Jenkins, bisa EWR, bisa set up dan sebagainya.
Dan penyedia identitas adalah yang akan menyimpan semua identitas.
Jadi, alih-alih semua identitas disimpan di penyedia layanan, kami memindahkan identitas itu ke situs penyedia
identitas.
Jadi mari kita lihat diagram alur kerja di mana Anda memiliki penyedia identitas, segala macam apa itu.
Dan penyedia layanan untuk ADP.
Jadi yang akan terjadi di sini adalah penggunaan login pertamanya ke penyedia identitas, penyedia
identitas akan memverifikasi apakah kredensial itu benar dan respons dikatakan.
Jadi pengguna akan melanjutkan dan mengirim respons itu ke penyedia layanan dan penyedia layanan.
Jika responnya sesuai dengan yang diharapkan, maka akan diarahkan ke konsultan manajemen.
Jadi ingatlah bahwa agar penyedia layanan menerima tanggapan ini, perlu ada kepercayaan
antara penyedia identitas dan penyedia layanan, yang akan dibangun sebelum seluruh proses
ini bekerja.
Jadi beginilah Samawi.
Dan tanggapan ini juga bisa disebut sebagai pernyataan Samael ini.
Jadi mari kita lihat ke tingkat tinggi atau lebih aliran dimulai ketika pengguna membuka ADP khawatir dan apakah
nama pengguna dan kata sandi dan memilih aplikasi yang sesuai atau aplikasi dapat menjadi jenkins
bermata dan seterusnya.
Jadi penyedia identitas akan memvalidasi kredensial dan izin terkait dan kemudian menggunakannya, menerima
pernyataan Samit dari bagian IDP dari respons.
Jadi, Anda tahu, kami sedang mendiskusikan tanggapan ini.
Ini pada dasarnya adalah pernyataan Samin yang diterima pengguna.
Jadi setelah pengguna menerima pernyataan ini, pengguna melakukan sebagian besar pernyataan Samin
itu ke halaman penandatanganan sumber dan penyedia layanan akan memvalidasi pernyataan tersebut pada validasi.
Penyedia layanan akan membuat kredensial sementara yang relevan dan juga membuat surat perintah penandatanganan untuk
konsol dan mengirimkannya kembali ke pengguna.
Jadi itu level tinggi di mana, Anda tahu, mari kita lihat demo dengan cepat sehingga ini menjadi lebih
dipahami.
Sekarang, langkah pertama yang kita bahas adalah pengguna harus mengirimkan nama pengguna dan kata sandi
ke penyedia identitas.
Jadi mereka akan menjadi perhatian, sesuatu yang mirip dengan ini, dan nama pengguna dan kata sandi pengguna
perlu dikirim.
Jadi mari kita coba di grid.
Jadi otentikasi telah berhasil.
Sekarang, jika Anda melihat ke sini, setelah otentikasi berhasil, pengguna harus memilih aplikasi
yang sesuai karena mungkin ada beberapa aplikasi yang akan hadir.
Jadi bisa database, bisa jenkins, bisa yang lain.
Jadi tergantung pada aplikasinya, karena penyedia layanan mengubah semua Anda sehingga Anda memiliki penyedia layanan
W. S. Jenkins, dll.
Jadi ini penting.
Jadi apa yang akan terjadi tergantung pada penyedia layanan yang dipilih pengguna, pernyataan Samin yang sesuai
akan diucapkan.
Jadi mari kita mencobanya.
Jadi segera setelah saya mengklik konsol manajemen yang saat ini bertahan, Anda
melihatnya Stammen dan pada dasarnya masuk dan memverifikasi dan Anda masuk ke akun.
Jadi di balik layar semacam itu telah terjadi.
Seperti Anda telah menerima pernyataan salmon, Asosiasi Salmon diteruskan ke penyedia layanan.
Penyedia layanan telah memvalidasi salmon itu, seperti yang saya katakan, dan dia akan menambahkan diarahkan ke konsol
manajemen.
Jadi mari kita lakukan satu hal untuk memahaminya dengan cara yang lebih baik.
Saya memiliki Sunday presser yang terpasang di dalam kru saya dan kami menggunakannya untuk melihat apa yang sebenarnya terjadi di balik layar untuk
memahami proses ini pada tinjauan tingkat tinggi.
Baiklah.
Jadi hal pertama yang kami diskusikan, pengguna akan mengklik konsol manajemen.
Jadi itu membuat Anda masuk dan Anda masuk.
Jadi ayo pergi.
Dan.
Jadi sekarang biarkan saya memaksimalkan.
Jadi hal pertama di sini pada dasarnya adalah permintaan gerbang sedang dibuat.
Jadi ini adalah permintaan gerbang yang dibuat ke ISS di sini.
Sekarang, jika Anda melihat ke sini, ada juga posting sekarang saat kami sedang mendiskusikan bahwa setelah pernyataan
ini diterima, maka Postingan sedang dikirim ke penyedia layanan.
Jadi jika Anda melihat permintaan posting khusus ini, posting ini telah dikirim ke halaman penandatanganan Dawe dengan salmon
ini.
Jadi ingatlah bahwa Eatables memiliki biro terpisah untuk otentikasi jika Anda menggunakan salmon.
Jadi ini adalah area yang tepat yang Anda perlukan untuk menenggelamkan pernyataan salmon Anda, seperti yang Anda
diskusikan setelah Anda menerima pernyataan salmon.
Pernyataan itu perlu dikirim ke spesifik dalam kasus perangkat.
Ini adalah Eweida ini.
Jadi di sinilah pos terjadi.
Dan jika Anda melihat ke salmon, ini adalah pernyataan salmon, yang dikirim ke, Anda tahu, jika
Anda turun di.
Ada bacaan kecil yang masuk dan dalam pengalihan ini, jika Anda melihat ke dalam lokasi,
ini adalah lokasi yang dibagikan oleh AWB.
Jadi mirip dengan apa yang kita diskusikan, solusi serupa sedang dikirim ke penyedia layanan,
penyedia layanan akan memverifikasi dan kemudian akan mengirim pengalihan ke konsol manajemen.
Dan itulah yang telah terjadi selama ini.
Jadi itulah gambaran tingkat tinggi tentang Simon.
Dan kami juga melihat bagaimana penyedia Sinon tunggal menggunakan Samin untuk melanjutkan dan memungkinkan pengguna untuk terhubung
ke penyedia layanan tertentu sehingga ini akan mengakhiri video ini.
Saya harap video ini memberikan informasi untuk Anda.
Dan sampai jumpa di video selanjutnya.