Di perusahaan besar mana pun, dan Grup Ritel X5 tidak terkecuali, seiring perkembangannya, jumlah proyek yang memerlukan otorisasi pengguna meningkat. Seiring waktu, transisi mulus pengguna dari satu aplikasi ke aplikasi lain diperlukan, dan kemudian ada kebutuhan untuk menggunakan satu server Single-Sing-On (SSO). Namun bagaimana bila penyedia identitas seperti AD atau lainnya yang tidak memiliki atribut tambahan sudah digunakan di berbagai proyek. Kelas sistem yang disebut "broker identifikasi" akan membantu. Yang paling fungsional adalah perwakilannya, seperti Keycloak, manajemen Akses Gravitee, dll. Paling sering, kasus penggunaan dapat berbeda: interaksi mesin, partisipasi pengguna, dll. Solusinya harus mendukung fungsionalitas yang fleksibel dan dapat diskalakan yang dapat menggabungkan semua persyaratan menjadi satu, dan solusi semacam itu perusahaan kami sekarang memiliki broker indikasi - Keycloak.
Keycloak adalah identitas sumber terbuka dan produk kontrol akses yang dikelola oleh RedHat. Ini adalah dasar untuk produk perusahaan menggunakan SSO - RH-SSO.
Konsep dasar
Sebelum Anda mulai berurusan dengan solusi dan pendekatan, Anda harus memutuskan dalam hal dan urutan proses:
Identifikasi adalah prosedur untuk mengenali subjek dengan pengenalnya (dengan kata lain, ini adalah definisi nama, login, atau nomor).
Otentikasi - ini adalah prosedur otentikasi (pengguna diperiksa dengan kata sandi, surat diperiksa dengan tanda tangan elektronik, dll.)
Otorisasi - ini adalah penyediaan akses ke sumber daya (misalnya, ke email).
Keycloak Broker Identitas
gantungan kunci adalah identitas sumber terbuka dan solusi manajemen akses yang dirancang untuk digunakan dalam IS di mana pola arsitektur layanan mikro dapat digunakan.
Keycloak menawarkan fitur-fitur seperti single sign-on (SSO), identitas perantara dan login sosial, federasi pengguna, adaptor klien, konsol admin, dan konsol manajemen akun.
Fungsi dasar yang didukung oleh Keycloak:
- Single-Sign On dan Single-Sign Out untuk aplikasi browser.
- Dukungan untuk OpenID/OAuth 2.0/SAML.
- Identity Brokering - autentikasi menggunakan OpenID Connect eksternal atau penyedia identitas SAML.
- Login Sosial - Dukungan Google, GitHub, Facebook, Twitter untuk identifikasi pengguna.
- Federasi Pengguna - sinkronisasi pengguna dari server LDAP dan Active Directory serta penyedia identitas lainnya.
- Jembatan Kerberos - menggunakan server Kerberos untuk autentikasi pengguna otomatis.
- Konsol Admin - untuk manajemen terpadu dari pengaturan dan opsi solusi melalui Web.
- Konsol Pengelolaan Akun - untuk pengelolaan mandiri profil pengguna.
- Kustomisasi solusi berdasarkan identitas korporat perusahaan.
- Otentikasi 2FA - Dukungan TOTP/HOTP menggunakan Google Authenticator atau FreeOTP.
- Alur Masuk - pendaftaran mandiri pengguna, pemulihan dan pengaturan ulang kata sandi, dan lainnya dimungkinkan.
- Manajemen Sesi - administrator dapat mengelola sesi pengguna dari satu titik.
- Pemeta Token - mengikat atribut pengguna, peran, dan atribut lain yang diperlukan ke token.
- Manajemen kebijakan yang fleksibel di seluruh ranah, aplikasi, dan pengguna.
- Dukungan CORS - Adaptor klien memiliki dukungan CORS bawaan.
- Antarmuka Penyedia Layanan (SPI) - Sejumlah besar SPI yang memungkinkan Anda menyesuaikan berbagai aspek server: aliran autentikasi, penyedia identitas, pemetaan protokol, dan lainnya.
- Adaptor klien untuk aplikasi JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Dukungan untuk bekerja dengan berbagai aplikasi yang mendukung perpustakaan OpenID Connect Relying Party atau Perpustakaan Penyedia Layanan SAML 2.0.
- Dapat diperluas menggunakan plugin.
Untuk proses CI/CD, serta otomatisasi proses manajemen di Keycloak, REST API/JAVA API dapat digunakan. Dokumentasi tersedia secara elektronik:
SISA API
API JAWA
Penyedia Identitas Perusahaan (On-Premise)
Kemampuan untuk mengautentikasi pengguna melalui layanan Federasi Pengguna.
Otentikasi pass-through juga dapat digunakan - jika pengguna mengautentikasi workstation dengan Kerberos (LDAP atau AD), maka mereka dapat diautentikasi secara otomatis ke Keycloak tanpa harus memasukkan nama pengguna dan sandi lagi.
Untuk otentikasi dan otorisasi pengguna lebih lanjut, dimungkinkan untuk menggunakan DBMS relasional, yang paling dapat diterapkan untuk lingkungan pengembangan, karena tidak melibatkan pengaturan dan integrasi yang panjang pada tahap awal proyek. Secara default, Keycloak menggunakan DBMS bawaan untuk menyimpan pengaturan dan data pengguna.
Daftar DBMS yang didukung sangat luas dan mencakup: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle, dan lainnya. Sejauh ini yang paling banyak diuji adalah Oracle 12C Release1 RAC dan Galera 3.12 cluster for MariaDB 10.1.19.
Penyedia identitas - login sosial
Dimungkinkan untuk menggunakan login dari jejaring sosial. Untuk mengaktifkan kemampuan mengautentikasi pengguna, gunakan konsol admin Keycloack. Perubahan dalam kode aplikasi tidak diperlukan dan fungsi ini tersedia di luar kotak dan dapat diaktifkan pada setiap tahap proyek.
Dimungkinkan untuk menggunakan penyedia Identitas OpenID/SAML untuk autentikasi pengguna.
Skenario otorisasi umum menggunakan OAuth2 di Keycloak
Alur Kode Otorisasi - digunakan dengan aplikasi sisi server. Salah satu jenis izin otorisasi yang paling umum karena cocok untuk aplikasi server di mana kode sumber aplikasi dan data klien tidak tersedia untuk pihak luar. Proses dalam hal ini didasarkan pada pengalihan. Aplikasi harus dapat berinteraksi dengan agen pengguna (user-agent), seperti browser web - untuk menerima kode otorisasi API yang dialihkan melalui agen pengguna.
aliran implisit - digunakan oleh aplikasi seluler atau web (aplikasi yang berjalan di perangkat pengguna).
Jenis izin otorisasi implisit digunakan oleh aplikasi seluler dan web di mana kerahasiaan klien tidak dapat dijamin. Jenis izin implisit juga menggunakan pengalihan agen pengguna, di mana token akses diteruskan ke agen pengguna untuk digunakan lebih lanjut dalam aplikasi. Ini membuat token tersedia untuk pengguna dan aplikasi lain di perangkat pengguna. Jenis izin otorisasi ini tidak mengautentikasi identitas aplikasi, dan prosesnya sendiri bergantung pada URL pengalihan (sebelumnya terdaftar di layanan).
Alur Implisit tidak mendukung token penyegaran token akses.
Alur Hibah Kredensial Klien β digunakan saat aplikasi mengakses API. Jenis izin otorisasi ini biasanya digunakan untuk interaksi server-ke-server yang harus dilakukan di latar belakang tanpa interaksi langsung dengan pengguna. Alur pemberian kredensial klien memungkinkan layanan web (klien rahasia) untuk menggunakan kredensialnya sendiri alih-alih menyamar sebagai pengguna untuk mengautentikasi saat memanggil layanan web lain. Untuk tingkat keamanan yang lebih tinggi, layanan panggilan dapat menggunakan sertifikat (bukan rahasia bersama) sebagai kredensial.
Spesifikasi OAuth2 dijelaskan di
Token JWT dan manfaatnya
JWT (Token Web JSON) adalah standar terbuka () yang mendefinisikan cara yang ringkas dan mandiri untuk mentransfer informasi antar pihak secara aman sebagai objek JSON.
Menurut standar, token terdiri dari tiga bagian dalam format base-64, dipisahkan oleh titik. Bagian pertama disebut header, yang berisi jenis token dan nama algoritma hash untuk mendapatkan tanda tangan digital. Bagian kedua menyimpan informasi dasar (pengguna, atribut, dll.). Bagian ketiga adalah tanda tangan digital.
. .
Jangan pernah menyimpan token di DB Anda. Karena token yang valid sama dengan kata sandi, menyimpan token itu seperti menyimpan kata sandi dalam teks biasa.
Token akses adalah token yang memberikan pemiliknya akses ke sumber daya server yang aman. Biasanya memiliki umur pendek dan dapat membawa informasi tambahan seperti alamat IP dari pihak yang meminta token.
Perbarui token adalah token yang memungkinkan klien untuk meminta token akses baru setelah masa berlakunya habis. Token ini biasanya dikeluarkan untuk jangka waktu yang lama.
Keuntungan utama menggunakan arsitektur layanan mikro:
- Kemampuan untuk mengakses berbagai aplikasi dan layanan melalui autentikasi satu kali.
- Dengan tidak adanya sejumlah atribut yang diperlukan di profil pengguna, dimungkinkan untuk memperkaya dengan data yang dapat ditambahkan ke payload, termasuk otomatis dan on-the-fly.
- Tidak perlu menyimpan informasi tentang sesi aktif, aplikasi server hanya perlu memverifikasi tanda tangannya.
- Kontrol akses yang lebih fleksibel melalui penambahan atribut di payload.
- Penggunaan tanda tangan token untuk header dan payload meningkatkan keamanan solusi secara keseluruhan.
Token JWT - komposisi
Judul - secara default, header hanya berisi jenis token dan algoritme yang digunakan untuk enkripsi.
Jenis token disimpan di kunci "typ". Kunci 'ketik' diabaikan di JWT. Jika kunci "typ" ada, nilainya harus JWT untuk menunjukkan bahwa objek ini adalah Token Web JSON.
Kunci kedua "alg" mendefinisikan algoritma yang digunakan untuk mengenkripsi token. Ini harus diatur ke HS256 secara default. Header dikodekan dalam base64.
{ "alg": "HS256", "type": "JWT"}
muatan (konten) - muatan menyimpan informasi apa pun yang perlu diperiksa. Setiap kunci dalam muatan dikenal sebagai "klaim". Misalnya, Anda dapat masuk ke aplikasi hanya dengan undangan (promo tertutup). Saat kami ingin mengundang seseorang untuk berpartisipasi, kami mengirimi mereka surat undangan. Penting untuk memeriksa apakah alamat email itu milik orang yang menerima undangan, jadi kami akan memasukkan alamat ini ke dalam payload, untuk ini kami menyimpannya di kunci "email"
{ "surel": "[email dilindungi]"}
Kunci dalam muatan bisa sewenang-wenang. Namun, ada beberapa yang dipesan:
- iss (Penerbit) - Mengidentifikasi aplikasi dari mana token dikirim.
- sub (Subjek) - menentukan subjek token.
- aud (Audience) adalah larik string atau URI peka huruf besar-kecil yang merupakan daftar penerima token ini. Ketika pihak penerima menerima JWT dengan kunci yang diberikan, ia harus memeriksa keberadaan dirinya sendiri di penerima - jika tidak, abaikan tokennya.
- exp (Waktu Kedaluwarsa) - Menunjukkan kapan token kedaluwarsa. Standar JWT mewajibkan semua implementasinya untuk menolak token yang kedaluwarsa. Kunci exp harus berupa stempel waktu dalam format unix.
- nbf (Not Before) adalah waktu dalam format unix yang menentukan saat token menjadi valid.
- iat (Dikeluarkan Pada) - Kunci ini menunjukkan waktu token dikeluarkan dan dapat digunakan untuk menentukan usia JWT. Kunci iat harus berupa stempel waktu dalam format unix.
- Jti (ID JWT) β sebuah string yang menentukan pengenal unik token ini, peka huruf besar-kecil.
Penting untuk dipahami bahwa payload tidak ditransmisikan dalam bentuk terenkripsi (walaupun token dapat disarangkan dan kemudian dimungkinkan untuk mengirimkan data terenkripsi). Oleh karena itu, tidak dapat menyimpan informasi rahasia apapun. Seperti header, muatannya disandikan base64.
Tanda tangan - saat kita memiliki title dan payload, kita bisa menghitung signature.
Disandikan Base64: header dan payload diambil, keduanya digabungkan menjadi string melalui titik. Kemudian string dan kunci rahasia ini dimasukkan ke dalam algoritme enkripsi yang ditentukan di header (kunci "alg"). Kuncinya bisa string apa saja. Senar yang lebih panjang akan lebih disukai karena akan memakan waktu lebih lama untuk diambil.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Membangun Arsitektur Kluster Failover Keycloak
Saat menggunakan satu klaster untuk semua project, ada peningkatan persyaratan untuk solusi SSO. Ketika jumlah proyek kecil, persyaratan ini tidak begitu terlihat untuk semua proyek, namun, dengan peningkatan jumlah pengguna dan integrasi, persyaratan ketersediaan dan kinerja meningkat.
Meningkatkan risiko kegagalan SSO tunggal meningkatkan persyaratan untuk arsitektur solusi dan metode yang digunakan untuk komponen redundan dan menyebabkan SLA yang sangat ketat. Dalam hal ini, lebih sering selama pengembangan atau tahap awal penerapan solusi, proyek memiliki infrastrukturnya sendiri yang tidak toleran terhadap kesalahan. Seiring kemajuan pembangunan, diperlukan untuk meletakkan peluang untuk pengembangan dan penskalaan. Paling fleksibel untuk membangun kluster failover menggunakan virtualisasi kontainer atau pendekatan hibrid.
Untuk bekerja dalam mode klaster Aktif/Aktif dan Aktif/Pasif, diperlukan untuk memastikan konsistensi data dalam database relasional - kedua node database harus direplikasi secara sinkron antara berbagai pusat data yang didistribusikan secara geografis.
Contoh paling sederhana dari instalasi yang toleran terhadap kesalahan.
Apa manfaat menggunakan cluster tunggal:
- Ketersediaan dan performa tinggi.
- Dukungan untuk mode operasi: Aktif / Aktif, Aktif / Pasif.
- Kemampuan untuk menskalakan secara dinamis - saat menggunakan virtualisasi kontainer.
- Kemungkinan pengelolaan dan pemantauan terpusat.
- Pendekatan terpadu untuk identifikasi/otentikasi/otorisasi pengguna dalam proyek.
- Interaksi yang lebih transparan antara berbagai proyek tanpa keterlibatan pengguna.
- Kemampuan untuk menggunakan kembali token JWT di berbagai proyek.
- Titik kepercayaan tunggal.
- Peluncuran proyek yang lebih cepat menggunakan virtualisasi layanan mikro/kontainer (tidak perlu mengangkat dan mengonfigurasi komponen tambahan).
- Dimungkinkan untuk membeli dukungan komersial dari vendor.
Apa yang Harus Diperhatikan Saat Merencanakan Cluster
DBMS
Keycloak menggunakan sistem manajemen basis data untuk menyimpan: ranah, klien, pengguna, dll.
Berbagai macam DBMS didukung: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak hadir dengan basis data relasional bawaannya sendiri. Disarankan untuk digunakan untuk lingkungan yang tidak dimuat - seperti lingkungan pengembangan.
Untuk bekerja dalam mode klaster Aktif/Aktif dan Aktif/Pasif, diperlukan konsistensi data dalam database relasional, dan kedua node klaster database direplikasi secara sinkron antara pusat data.
Cache terdistribusi (Infinspan)
Agar kluster berfungsi dengan benar, diperlukan sinkronisasi tambahan dari jenis cache berikut menggunakan JBoss Data Grid:
Sesi autentikasi - digunakan untuk menyimpan data saat mengautentikasi pengguna tertentu. Permintaan dari cache ini biasanya hanya menyertakan browser dan server Keycloak, bukan aplikasi.
Token tindakan digunakan untuk skenario di mana pengguna perlu mengonfirmasi tindakan secara asinkron (melalui email). Misalnya, selama aliran lupa kata sandi, cache actionTokens Infinispan digunakan untuk melacak metadata tentang token tindakan terkait yang telah digunakan, sehingga tidak dapat digunakan kembali.
Caching dan pembatalan data persisten - digunakan untuk meng-cache data persisten untuk menghindari kueri yang tidak perlu ke database. Ketika server Keycloak memperbarui data, semua server Keycloak lainnya di semua pusat data perlu mengetahuinya.
Bekerja - Hanya digunakan untuk mengirim pesan yang tidak valid antara node cluster dan pusat data.
Sesi pengguna - digunakan untuk menyimpan data tentang sesi pengguna yang valid selama durasi sesi browser pengguna. Cache harus memproses permintaan HTTP dari pengguna akhir dan aplikasi.
Perlindungan brute force - digunakan untuk melacak data tentang login yang gagal.
Penyeimbang beban
Penyeimbang muatan adalah titik masuk tunggal ke keycloak dan harus mendukung sesi lengket.
Server Aplikasi
Mereka digunakan untuk mengontrol interaksi komponen satu sama lain dan dapat divirtualisasikan atau dikemas menggunakan alat otomasi yang ada dan penskalaan dinamis alat otomasi infrastruktur. Skenario penerapan paling umum di OpenShift, Kubernates, Rancher.
Ini menyimpulkan bagian pertama - bagian teoretis. Dalam seri artikel berikutnya, contoh integrasi dengan berbagai penyedia identitas dan contoh pengaturan akan dianalisis.
Sumber: www.habr.com