latar belakang
Teman -teman yang telah berubah dari aplikasi monolitik tradisional ke Spring Cloud bertanya kepada saya, bagaimana mengelola izin layanan mikro di bawah Spring Cloud ? Bagaimana cara merancang lebih masuk akal? Dari perspektif yang besar, disebut izin layanan, yang dibagi menjadi tiga bagian:用户认证,用户权限, dan服务校验.
Otentikasi pengguna
Aplikasi monolitik tradisional mungkin terbiasa dengan keberadaan sesi. Setelah layanan mikro Spring Cloud, sesi dapat diselesaikan dengan sesi terdistribusi, tetapi mereka bukan strategi terbaik. Beberapa orang mulai menerapkan keamanan Spring Cloud yang dikombinasikan dengan OAuth2 , yang terkenal dengan OAuth2-nya. Kemudian, untuk mengoptimalkan masalah penyimpanan Access Token di OAuth 2 dan meningkatkan ketersediaan dan skalabilitas layanan back-end, ada metode verifikasi token yang lebih baik JWT (token web JSON). Satu hal yang perlu ditekankan di sini adalah bahwa OAuth2 dan JWT tidak sebanding sama sekali, mereka adalah dua hal yang sama sekali berbeda.
OAuth2是一种授权框架, sedangkan JWT adalah protokol otentikasi
Kerangka otentikasi OAuth2 OAuth2 berisi empat peran:
OAuth2 berisi 4 mode otorisasi
Di antara mereka, proses operasi OAuth2 ditunjukkan pada gambar di bawah ini, dikutip dari RFC 6749:
+--------++------------------------+| |-(a)-Permintaan Otorisasi-> | Sumber Daya || | | | | Pemilik || | <-(b)-Hibah Otorisasi --- | || | +------------------------+| || | +-------------------+| |-(c)-Hibah Otorisasi-> | Otorisasi || Klien | | | Server || |<-(D)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----->| Sumber Daya || | | Server || <-(f) --- Sumber Daya yang Dilindungi --- | |+--------++---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Di Spring Cloud OAuth2, semua permintaan untuk mengakses Sumber Daya Layanan Mikro membawa token di header HTTP. Layanan yang diakses kemudian akan meminta server otorisasi untuk memverifikasi validitas token. Dengan cara ini, kita membutuhkan两次或者更多次permintaan. Semua verifikasi validitas token jatuh di server otorisasi, yang telah menjadi hambatan yang sangat besar untuk perluasan horizontal sistem kami.
Protokol Sertifikasi JWT
授权服务器Serialisasi informasi pengguna dan ruang lingkup otorisasi dan menempatkan string JSON, kemudian menggunakan Base64 untuk menyandikannya, dan akhirnya menandatangani string dengan kunci pribadi di server otorisasi untuk mendapatkan JSON Web Token .
Dengan asumsi bahwa semua server sumber daya lainnya akan memiliki kunci publik RSA. Ketika server sumber daya menerima permintaan untuk memiliki token di header HTTP, server sumber daya dapat memperoleh token dan memverifikasi apakah ia menggunakan tanda tangan kunci pribadi yang benar (apakah telah ditandatangani oleh server yang berwenang, yaitu, verifikasi tanda tangan). Setelah lulus verifikasi, informasi verifikasi yang valid yang terkandung dalam TOEKN akan diperoleh setelah deserialisasi.
Di antara mereka, diagram alur operasi utama adalah sebagai berikut:
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Melalui metode di atas, kami dapat menyelesaikan otentikasi pengguna berbasis layanan dengan baik.
Izin pengguna
Semua orang menyukai shiro untuk memblokir izin aplikasi tubuh tunggal tradisional, dan cukup mudah digunakan. Tetapi begitu terpecah, izin mulai tersebar di berbagai API. Apakah shiro masih berfungsi? Dalam proyek ini, saya tidak menggunakan shiro . Setelah ujung depan dan belakang dipisahkan, interaksi adalah token, layanan backend adalah tanpa kewarganegaraan, tombol front-end sumber daya, dan di mana kita dapat mengelola izin?
Abstrak dan Desain
Sebelum memperkenalkan desain inti yang fleksibel, izinkan saya memperkenalkan konsep pratinjau kepada Anda: RBAC (kontrol akses berbasis peran, kontrol akses berbasis peran), yang berarti bahwa pengguna bergaul dengan izin melalui peran. Sederhananya, pengguna memiliki beberapa peran, dan setiap peran memiliki beberapa izin.
RBAC sebenarnya adalah model analitik, terutama dibagi menjadi: model dasar RBAC0 (inti RBAC), model peran hierarki RBAC1 (hierarki RBAC), model pembatasan peran RBAC2 (kendala RBAC) dan model terpadu RBAC3 (menggabungkan RBAC).
UML inti
Ini adalah diagram hubungan RBAC abstrak penulis setelah beberapa skenario bisnis
Deskripsi kelas
Kelompok
Grup atau grup, koleksi dengan sejumlah izin tertentu, juga bisa menjadi pembawa izin.
子类: Pengguna (pengguna), peran (peran), posisi (pos), unit (departemen). Melalui komposisi spesifik pengguna, grup atau kelompok skenario bisnis yang berbeda dibentuk, dan izin pengguna diperoleh melalui otorisasi ke kelas induk grup atau grup.
Izin
Izin, integrasi dengan sejumlah sumber daya tertentu, juga dapat menjadi pembawa sumber daya.
Sumber daya
Ada sumber daya di bawah izin, dan sumber sumber daya meliputi: menu (menu), tombol (izin tindakan), elemen halaman (tombol, tab, dll.), Izin data, dll.
Program
Program, rendering operator untuk kontrol izin terkait, dapat dipasang di beberapa menu.
Komposisi Dasar Program Web Umum
Hubungan antara model dan layanan mikro
Jika semua antarmuka API setelah layanan Spring Cloud didefinisikan sebagai Resources di atas, maka kita dapat melihat situasi seperti itu.
Misalnya, jika pengguna menambahkan, menghapus, memodifikasi dan memeriksa, halaman kami akan melakukan ini.
| Elemen halaman | Pengkodean Sumber Daya | Sumber Daya URI | Metode Permintaan Sumber Daya |
|---|---|---|---|
| Pertanyaan | user_btn_get | /API/pengguna/{id} | MENDAPATKAN |
| Meningkatkan | user_btn_add | /API/Pengguna | POS |
| edit | user_btn_edit | /API/pengguna/{id} | MELETAKKAN |
| menghapus | user_btn_del | /API/pengguna/{id} | MENGHAPUS |
Setelah mengabstraksi ke dalam hubungan pemetaan di atas, sumber daya ujung depan dan belakang kami dirujuk, membuatnya lebih mudah bagi kami untuk mengesahkan izin grup pengguna. Misalnya, saya memberikan izin pengguna untuk menambah dan menghapus. Di前端kita hanya perlu memverifikasi apakah资源编码ada atau tidak untuk mengontrol tampilan dan menyembunyikan tombol, sementara di后端, kita hanya perlu mencegat secara seragam dan menentukan apakah pengguna memiliki请求方式URI dan yang sesuai.
Adapun apakah intersepsi izin terpadu ditempatkan di Gateway Zuul atau pada pencegat layanan backend spesifik (filter, inteceptor), itu dapat dengan mudah diimplementasikan. Tidak terbatas pada invasif kode. Diagram alur menempatkan Zuul adalah sebagai berikut:
Jika intersepsi izin yang disatukan ditempatkan pada Zuul , akan ada masalah, yaitu, apakah layanan back-end aman, dan layanan hanya perlu dipanggil melalui pusat pendaftaran. Ini melibatkan modul ketiga di belakang, otentikasi antara layanan.
Otentikasi antar layanan
Karena kita semua tahu bahwa layanan secara langsung disebut prosedur jarak jauh setelah mereka menemukan klien melalui pusat pendaftaran. Kita perlu melindungi setiap layanan dan antarmuka sensitif dalam produksi. Proses topik ini adalah sebagai berikut:
Metode implementasi penulis didasarkan pada FeignClient Inteceprot Spring Cloud (secara otomatis berlaku untuk token layanan, lulus konteks saat ini) dan Mvc Inteceptor (verifikasi token layanan, perbarui konteks saat ini) untuk lebih melindungi keamanan layanan.
Setelah menggabungkan fitur -fitur Spring Cloud, grafik aliran keseluruhan adalah sebagai berikut:
Titik Optimalisasi
Meskipun keamanan antarmuka API dipastikan melalui verifikasi legalitas pengguna yang disebutkan di atas, intersepsi izin pengguna dan otentikasi antara layanan, Http访问频率relatif tinggi. Ketika jumlah permintaan meningkat, masalah慢akan sangat jelas. Strategi optimisasi tertentu dapat dipertimbangkan, seperti cache izin pengguna, distribusi dan penyimpanan campuran informasi otorisasi layanan, dan penyegaran rutin token otentikasi layanan.
Kesimpulan
Di atas adalah ide umum saya dalam proyek. Teman yang tertarik dapat belajar dari proyek open source saya. Selamat datang di Star:
- Gitchina: https://gitee.com/minull/ace-security (JWT, izin pengguna)
- Github: https://github.com/wxiaoqi/ace-security
- Gitchina: http://git.oschina.net/geek_qi/ace-gate (otentikasi layanan)
Di atas adalah semua konten artikel ini. Saya berharap ini akan membantu untuk pembelajaran semua orang dan saya harap semua orang akan lebih mendukung wulin.com.