⭐️ 🌆 ⛎ SSO pada arsitektur layanan mikro. Kami menggunakan Keycloak. Bagian nomor 1 🤟🏽 ▫️ 👩🏼‍🤝‍👨🏿

Di perusahaan besar mana pun, Grup Ritel X5 tidak terkecuali, karena jumlah proyek yang memerlukan otentikasi pengguna meningkat seiring dengan meningkatnya jumlah proyek. Seiring waktu, diperlukan transisi pengguna yang mulus dari satu aplikasi ke aplikasi lain dan kemudian ada kebutuhan untuk menggunakan server tunggal Single-Sing-On (SSO). Tetapi bagaimana dengan ketika penyedia identitas seperti AD atau orang lain yang tidak memiliki atribut tambahan sudah digunakan dalam berbagai proyek. Kelas sistem yang disebut "broker identitas" akan datang untuk menyelamatkan. Yang paling fungsional adalah perwakilannya, seperti Keycloak, manajemen Gravitee Access, dll. Paling sering, skenario penggunaan bisa berbeda: interaksi mesin, partisipasi pengguna, dll. Solusi harus mendukung fungsi yang fleksibel dan dapat diskalakan,mampu menggabungkan semua persyaratan dalam satu, dan solusi seperti itu di perusahaan kami sekarang adalah broker indikator - Keycloak.

Keycloak adalah produk open source untuk otentikasi dan kontrol akses yang didukung oleh RedHat. Ini adalah dasar untuk produk perusahaan menggunakan SSO - RH-SSO.

Konsep dasar

Sebelum Anda mulai berurusan dengan keputusan dan pendekatan, Anda harus menentukan syarat dan urutan proses:

Identifikasi adalah proses mengenali subjek dengan pengidentifikasi (dengan kata lain, itu menentukan nama, login atau nomor).

Otentikasi adalah prosedur otentikasi (pengguna diperiksa dengan kata sandi, email diverifikasi oleh tanda tangan elektronik, dll.)

Otorisasi adalah penyediaan akses ke beberapa sumber daya (misalnya, email).

Broker Identitas Keycloak

Keycloak adalah identitas sumber terbuka dan solusi manajemen akses yang dirancang untuk digunakan dalam IC di mana pola arsitektur layanan mikro dapat digunakan.

Keycloak menawarkan fitur-fitur seperti sistem masuk tunggal (SSO), identifikasi pialang dan login sosial, federasi pengguna, adaptor klien, konsol administrator, dan konsol manajemen akun.

Fungsionalitas dasar yang didukung di Keycloak:

Single-Sign On dan Single-Sign Out untuk aplikasi berbasis browser.
Dukungan untuk OpenID / OAuth 2.0 / SAML.
Perantara Identitas - Otentikasi menggunakan penyedia OpenID Connect atau SAML identitas eksternal.
Login Sosial - dukungan untuk Google, GitHub, Facebook, Twitter untuk identifikasi pengguna.
User Federation – LDAP Active Directory .
Kerberos bridge – Kerberos .
Admin Console — Web.
Account Management Console – .
.
2FA Authentication – TOTP/HOTP Google Authenticator FreeOTP.
Login Flows – , .
Session Management – .
Token Mappers – , .
realm, application .
CORS Support – CORS.
Service Provider Interfaces (SPI) – SPI, : , , .
JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
, OpenID Connect Relying Party library SAML 2.0 Service Provider Library.
plugins.

Untuk proses CI / CD, serta otomatisasi proses manajemen di Keycloak, REST API / JAVA API dapat digunakan. Dokumentasi tersedia dalam bentuk elektronik:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
API JAVA https://www.keycloak.org/docs-api/8.0/javadocs /index.html

Penyedia Identitas Perusahaan (Di Lokasi)

Kemampuan untuk mengotentikasi pengguna melalui layanan Federasi Pengguna.

Otentikasi pass-through juga dapat digunakan - jika pengguna mengotentikasi di workstation dengan Kerberos (LDAP atau AD), maka mereka dapat diautentikasi secara otomatis pada Keycloak tanpa harus memberikan nama pengguna dan kata sandi mereka lagi.

Untuk otentikasi dan otorisasi lebih lanjut dari pengguna, dimungkinkan untuk menggunakan DBMS relasional, yang paling berlaku untuk lingkungan pengembangan, karena tidak memerlukan pengaturan jangka panjang dan integrasi dalam 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. Yang paling diuji saat ini adalah Oracle 12C Release1 RAC dan cluster Galera 3.12 untuk MariaDB 10.1.19.

Penyedia Identitas - login sosial

Dimungkinkan untuk menggunakan login dari jejaring sosial. Untuk mengaktifkan kemampuan untuk mengotentikasi pengguna, konsol admin Keycloack digunakan. Perubahan dalam kode aplikasi tidak diperlukan dan fungsi ini tersedia "di luar kotak" dan dapat diaktifkan pada setiap tahap proyek.

Untuk mengotentikasi pengguna, dimungkinkan untuk menggunakan penyedia Identitas OpenID / SAML.

Skenario Otorisasi Khas Menggunakan OAuth2 di Keycloak

Alur Kode Otorisasi - digunakan dengan aplikasi sisi server. Salah satu jenis izin otorisasi yang paling umum, karena sangat cocok untuk aplikasi server di mana kode sumber aplikasi dan data klien tidak dapat diakses oleh orang luar. Proses dalam hal ini didasarkan pada pengalihan. Aplikasi harus dapat berinteraksi dengan agen pengguna (agen-pengguna), seperti browser web - untuk menerima kode otorisasi API yang dialihkan melalui agen pengguna.

Implisit Flow - digunakan oleh aplikasi seluler atau web (aplikasi yang berjalan di perangkat pengguna).

Jenis izin otorisasi implisit digunakan oleh aplikasi seluler dan web di mana privasi klien tidak dapat dijamin. Jenis izin implisit juga menggunakan pengalihan agen pengguna, dan token akses diteruskan ke agen pengguna untuk digunakan lebih lanjut dalam aplikasi. Ini membuat token tersedia untuk pengguna dan aplikasi lain di perangkat pengguna. Dengan jenis izin otorisasi ini, aplikasi tidak diautentikasi, dan prosesnya sendiri bergantung pada URL pengalihan (sebelumnya terdaftar dalam layanan).

Aliran Tersirat tidak mendukung token penyegaran.
Alur Hibah Kredensial Klien - digunakan ketika aplikasi mengakses API. Jenis izin otorisasi ini biasanya digunakan untuk interaksi server-ke-server yang harus berjalan di latar belakang tanpa interaksi pengguna langsung. Alur kredensial klien memungkinkan layanan web (klien rahasia) untuk menggunakan kredensial sendiri alih-alih menyamar sebagai pengguna untuk otentikasi ketika memanggil layanan web lain. Untuk tingkat keamanan yang lebih tinggi, dimungkinkan bagi layanan panggilan untuk menggunakan sertifikat (alih-alih rahasia bersama) sebagai kredensial.

Spesifikasi OAuth2 dijelaskan dalam
RFC-6749
RFC-8252
RFC-6819

Token JWT dan kelebihannya

JWT (JSON Web Token) adalah standar terbuka ( https://tools.ietf.org/html/rfc7519 ) yang mendefinisikan metode yang ringkas dan mandiri untuk mentransfer informasi antara pihak-pihak dengan aman sebagai objek JSON.

Menurut standar, token terdiri dari tiga bagian dalam format basis-64, dipisahkan oleh titik-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.

<header yang disandikan>. <payload yang disandikan>. <signature>
Jangan pernah menyimpan token di basis data Anda. Karena token yang valid setara dengan kata sandi, menyimpan token sama seperti menyimpan kata sandi dalam teks yang jelas.
Token akses adalah token yang memberikan pemiliknya akses ke sumber daya server yang dilindungi. Biasanya memiliki umur yang pendek dan dapat membawa informasi tambahan, seperti alamat IP pihak yang meminta token ini.

Token penyegaran adalah token yang memungkinkan klien untuk meminta token akses baru setelah masa pakainya berakhir. Token ini biasanya dikeluarkan untuk waktu yang lama.

Keuntungan utama aplikasi dalam arsitektur layanan mikro:

Kemampuan untuk mengakses berbagai aplikasi dan layanan melalui otentikasi satu kali.
Dengan tidak adanya sejumlah atribut yang diperlukan dalam profil pengguna, dimungkinkan untuk memperkaya dengan data yang dapat ditambahkan ke muatan, termasuk otomatis dan on-the-fly.
Tidak perlu menyimpan informasi tentang sesi aktif, aplikasi server hanya harus memverifikasi tanda tangan.
Kontrol akses yang lebih fleksibel dengan atribut tambahan dalam payload.
Menggunakan tanda tangan token untuk header dan payload meningkatkan keamanan solusi secara keseluruhan.

Token JWT - Komposisi

Header - secara default, header hanya berisi jenis token dan algoritma yang digunakan untuk enkripsi.

Jenis token disimpan di kunci "ketik". Kunci "ketik" diabaikan di JWT. Jika tombol ketik ada, nilainya harus JWT untuk menunjukkan bahwa objek ini adalah Token Web JSON.

Kunci alg kedua mendefinisikan algoritma yang digunakan untuk mengenkripsi token. Secara default, ini harus diatur ke HS256. Header dikodekan dalam base64.

{"alg": "HS256", "typ": "JWT"}
Payload (konten) - payload menyimpan informasi apa pun yang perlu diverifikasi. Setiap kunci dalam muatan dikenal sebagai "pernyataan". Misalnya, aplikasi hanya dapat dimasukkan melalui undangan (promo tertutup). Ketika kami ingin mengundang seseorang untuk berpartisipasi, kami mengiriminya surat undangan. Penting untuk memverifikasi bahwa alamat email itu milik orang yang menerima undangan, jadi kami akan memasukkan alamat ini dalam payload, untuk ini kami akan menyimpannya di kunci “e-mail”

{"email": "example@x5.ru"}
Kunci dalam payload bisa sewenang-wenang. Namun, ada beberapa yang dipesan:

iss (Issuer) - mendefinisikan aplikasi dari mana token dikirim.
sub (Subjek) - mendefinisikan topik token.
aud (Audience) – URI, . JWT , — .
exp (Expiration Time) — , . JWT , . Exp unix .
nbf (Not Before) — unix , , .
iat (Issued At) — , JWT. iat unix .
Jti (JWT ID) — , c .

Penting untuk dipahami bahwa muatan tidak ditransmisikan dalam bentuk terenkripsi (meskipun token dapat disematkan dan kemudian dimungkinkan untuk mengirimkan data terenkripsi). Karena itu, tidak mungkin menyimpan informasi rahasia di dalamnya. Seperti tajuk, payload dikodekan dalam base64.
Tanda tangan - saat kami memiliki tajuk dan muatan, kami dapat menghitung tanda tangan.

Base64 disandikan: header dan payload diambil, mereka digabungkan menjadi garis melalui titik. Kemudian baris ini dan kunci rahasia dikirim ke input dari algoritma enkripsi yang ditentukan dalam header (kunci "alg"). Kuncinya bisa berupa string apa saja. String yang lebih panjang akan lebih disukai, karena akan membutuhkan lebih banyak waktu untuk mencocokkan.

{"alg": "RSA1_5", "payload": "A128CBC-HS256"}

Arsitektur Cluster Keailloak Failover

Saat menggunakan satu kluster untuk semua proyek, ada peningkatan persyaratan untuk solusi untuk SSO. Ketika jumlah proyek kecil, persyaratan ini tidak begitu terlihat untuk semua proyek, tetapi dengan peningkatan jumlah pengguna dan integrasi, persyaratan untuk ketersediaan dan peningkatan produktivitas.

Meningkatkan risiko kegagalan SSO tunggal meningkatkan persyaratan untuk arsitektur solusi dan metode yang digunakan untuk redundansi komponen dan mengarah ke SLA yang sangat ketat. Dalam hal ini, lebih sering ketika mengembangkan atau pada tahap awal implementasi solusi, proyek memiliki infrastruktur sendiri yang tahan terhadap kesalahan. Saat Anda berkembang, Anda perlu meletakkan kemungkinan pengembangan dan penskalaan. Yang paling fleksibel adalah membangun kluster failover menggunakan virtualisasi wadah atau pendekatan hibrida.

Untuk bekerja dalam kluster Aktif / Aktif dan Aktif / Pasif, diperlukan untuk memastikan konsistensi data dalam basis data relasional - kedua simpul basis data harus direplikasi secara serempak antara berbagai pusat data yang didistribusikan secara geografis.

Contoh paling sederhana dari instalasi gagal-aman.

Apa manfaat menggunakan satu kluster:

Ketersediaan dan kinerja tinggi.
Dukungan untuk mode operasi: Aktif / Aktif, Aktif / Pasif.
Kemampuan untuk secara dinamis mengukur - saat menggunakan virtualisasi wadah.
Kemungkinan manajemen dan pemantauan terpusat.
Pendekatan terpadu untuk identifikasi / otentikasi / otorisasi pengguna dalam proyek.
Interaksi yang lebih transparan antara berbagai proyek tanpa partisipasi pengguna.
Kemampuan untuk menggunakan kembali token JWT di berbagai proyek.
Satu titik kepercayaan.
Peluncuran proyek yang lebih cepat menggunakan microservices / virtualisasi wadah (tidak perlu menaikkan dan mengkonfigurasi komponen tambahan).
Mungkin perolehan dukungan komersial dari vendor.

Hal-hal yang perlu dipertimbangkan ketika merencanakan sebuah cluster

DBMS

Keycloak menggunakan sistem manajemen DBMS untuk menyimpan: ranah, klien, pengguna, dll
. Berbagai DBMS didukung: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak dilengkapi dengan basis data relasional bawaan. Dianjurkan untuk menggunakan lingkungan yang tidak dimuat seperti lingkungan pengembangan.

Untuk beroperasi dalam kluster Aktif / Aktif dan Aktif / Pasif, diperlukan untuk memastikan konsistensi data dalam basis data relasional, dan kedua node dari kluster basis data direplikasi secara serempak antara pusat data.

Cache Terdistribusi (Infinspan)

Agar kluster berfungsi dengan benar, diperlukan sinkronisasi tambahan dari tipe cache berikut menggunakan JBoss Data Grid:

Sesi otentikasi - digunakan untuk menyimpan data selama autentikasi pengguna tertentu. Permintaan dari cache ini biasanya hanya menyertakan browser dan server Keycloak, bukan aplikasi.

Token tindakan - digunakan untuk skenario saat pengguna perlu mengonfirmasi tindakan secara tidak sinkron (melalui email). Misalnya, selama aliran lupa kata sandi, cache Infinispan actionTokens digunakan untuk melacak metadata tentang penanda tindakan terkait yang telah digunakan, sehingga tidak dapat digunakan kembali.

Caching dan pembatalan data persisten - digunakan untuk men-cache data persisten untuk menghindari permintaan basis data yang tidak perlu. Ketika server Keycloak memperbarui data, semua server Keycloak lainnya di semua pusat data harus mengetahui hal ini.

Bekerja - digunakan hanya untuk mengirim pesan yang tidak valid antara node cluster dan pusat data.

Sesi pengguna - digunakan untuk menyimpan data tentang sesi pengguna yang valid untuk sesi browser pengguna. Cache harus menangani permintaan HTTP dari pengguna akhir dan aplikasi.

Brute force protection - digunakan untuk melacak data login yang gagal.

Penyeimbang beban

Load balancer adalah titik masuk tunggal keycloak dan harus mendukung sesi lengket.

Server aplikasi

Mereka digunakan untuk mengontrol interaksi komponen di antara mereka sendiri dan dapat divirtualisasi atau kemas menggunakan alat otomasi yang ada dan secara dinamis meningkatkan alat otomasi infrastruktur. Skenario penyebaran yang paling umum di OpenShift, Kubernetes, Rancher.

Tentang ini, bagian pertama - teoretis - telah berakhir. Dalam seri artikel berikut, contoh integrasi dengan berbagai penyedia identifikasi dan contoh konfigurasi akan dibahas.

SSO pada arsitektur layanan mikro. Kami menggunakan Keycloak. Bagian nomor 1