Sistem otorisasi dan otentikasi untuk layanan mikro dan konsumen

Kami berencana untuk memperbaiki sistem perusahaan kami menjadi sistem berbasis layanan mikro. Layanan mikro ini akan digunakan oleh aplikasi internal perusahaan kami sendiri dan oleh mitra pihak ketiga jika diperlukan. Satu untuk pemesanan, satu untuk produk dll.

Kami tidak yakin bagaimana menangani peran dan cakupan. Idenya adalah untuk membuat 3 peran pengguna dasar seperti Admin, Agen dan Pengguna Akhir dan membiarkan aplikasi konsumen untuk menyempurnakan cakupan jika diperlukan.

• Admin dapat membuat, memperbarui, membaca, dan menghapus semua sumber daya secara default (untuk perusahaan mereka).
• Agen dapat membuat, memperbarui, dan membaca data untuk perusahaan mereka.
• Pengguna Akhir dapat membuat, memperbarui, menghapus dan membaca data, tetapi tidak dapat mengakses titik akhir yang sama dengan agen atau admin. Mereka juga akan dapat membuat atau memodifikasi data, hanya saja tidak setingkat agen atau admin. Misalnya, pengguna akhir dapat memperbarui atau membaca info akun mereka, sama seperti agen akan dapat melakukannya untuk mereka, tetapi mereka tidak dapat melihat atau memperbarui catatan admin.

Katakanlah agen secara default dapat membuat, membaca, dan memperbarui setiap sumber daya untuk perusahaan mereka dan itu adalah ruang lingkup maksimum mereka yang dapat diminta untuk token / sesi mereka, tetapi pengembang aplikasi klien (pengguna API) telah memutuskan bahwa salah satu agen mereka dapat baca dan buat hanya sumber daya tertentu.

Apakah ini praktik yang lebih baik untuk menangani ini dalam keamanan internal kami, dan biarkan mereka menulis data itu di basis data kami, atau biarkan klien menanganinya secara internal dengan meminta token dengan cakupan yang lebih rendah, dan biarkan mereka menulis agen mana yang akan memiliki ruang lingkup di basis data mereka ? Dengan cara ini kita hanya perlu melacak token scope.

Kelemahan dari ini, adalah bahwa tim kami juga perlu membuat mekanisme akses yang disempurnakan dalam aplikasi internal kami.

Dengan cara berpikir seperti ini, layanan mikro dan sistem otorisasi mereka tidak boleh diganggu dengan kebutuhan klien, karena mereka hanya konsumen dan bukan bagian dari sistem (meskipun beberapa konsumen tersebut adalah aplikasi internal kita sendiri)?

Apakah delegasi ini pendekatan yang baik?

Otentikasi dan otorisasi selalu merupakan topik yang bagus

Saya akan mencoba menjelaskan kepada Anda bagaimana kami menangani otorisasi dalam layanan multi-tenant saat ini yang sedang saya kerjakan. Otentikasi dan otorisasi berbasis token, menggunakan standar terbuka JSON Web Token. Layanan memperlihatkan API REST yang dapat diakses oleh segala jenis klien (aplikasi web, seluler, dan desktop). Ketika pengguna berhasil diautentikasi, layanan menyediakan token akses yang harus dikirim pada setiap permintaan ke server.

Jadi izinkan saya memperkenalkan beberapa konsep yang kami gunakan berdasarkan pada bagaimana kami memandang dan memperlakukan data pada aplikasi server.

Sumber Daya : Ini adalah unit atau kelompok data apa pun yang dapat diakses klien melalui layanan. Untuk semua sumber daya yang ingin kita kendalikan, kita menetapkan satu nama. Misalnya, memiliki aturan titik akhir berikutnya kita dapat menamainya sebagai berikut:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

Jadi katakanlah sejauh ini kami memiliki tiga sumber daya dalam layanan kami; product, paymentdan order.

Tindakan : Ini adalah operasi yang dapat dilakukan pada sumber daya, seperti, membaca, membuat, memperbarui, menghapus, dll. Tidak perlu hanya menjadi operasi CRUD klasik, Anda dapat memiliki tindakan bernama follow, misalnya, jika Anda ingin mengekspos layanan yang menyebarkan beberapa jenis informasi menggunakan WebSockets.

Kemampuan : Kemampuan untuk melakukan actionpada a resource. Contohnya; baca produk, buat produk, dll. Ini pada dasarnya hanya sumber daya / tindakan pasangan. Tetapi Anda dapat menambahkan nama dan deskripsi juga.

Peran : Seperangkat kemampuan yang dapat dimiliki pengguna. Misalnya, peran Cashierdapat memiliki kemampuan "membaca pembayaran", "membuat pembayaran" atau peran Sellerdapat memiliki kemampuan "membaca produk", "membaca pesanan", "memperbarui pesanan", "menghapus pesanan".

Akhirnya, pengguna dapat memiliki berbagai peran yang ditugaskan padanya.

Penjelasan

Seperti yang saya katakan sebelumnya, kami menggunakan JSON Web Token dan kemampuan yang dimiliki pengguna dinyatakan dalam payload token. Jadi, misalkan kita memiliki pengguna dengan peran kasir dan penjual pada saat yang sama, untuk toko ritel kecil. Payload akan terlihat seperti ini:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

Seperti yang Anda lihat dalam scopesklaim, kami tidak menentukan nama peran (kasir, penjual), sebaliknya, hanya sumber daya dan tindakan yang terlibat yang ditentukan. Ketika klien mengirim permintaan ke titik akhir, layanan harus memeriksa apakah token akses berisi sumber daya dan tindakan yang diperlukan. Misalnya, GETpermintaan ke titik akhir /payments/88akan berhasil, tetapi DELETEpermintaan ke titik akhir yang sama harus gagal.

• Bagaimana mengelompokkan dan memberi nama sumber daya dan bagaimana mendefinisikan serta menyebutkan tindakan dan kemampuan akan menjadi keputusan yang dibuat oleh pengembang.

• Apa peran dan kemampuan apa yang akan dimiliki oleh peran itu, adalah keputusan yang dibuat oleh pelanggan.

Tentu saja, Anda harus menambahkan properti tambahan ke payload untuk mengidentifikasi pengguna dan pelanggan (penyewa) yang mengeluarkan token.

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

Dengan metode ini, Anda dapat menyempurnakan akses akun pengguna apa pun ke layanan Anda. Dan yang paling penting, Anda tidak harus membuat berbagai peran yang telah ditentukan dan statis, seperti Admin, Agen, dan Pengguna Akhir saat Anda tunjukkan dalam pertanyaan Anda. Sebuah Super User akan menjadi pengguna yang memiliki sebuah roledengan semua resourcesdan actionslayanan yang ditugaskan untuk itu.

Sekarang, Bagaimana jika ada 100 sumber daya dan kami ingin peran yang memberikan akses ke semua atau hampir semuanya ?. Muatan token kami akan sangat besar. Itu diselesaikan dengan bersarang sumber daya dan hanya menambahkan sumber daya induk dalam lingkup token akses.

Otorisasi adalah topik rumit yang harus ditangani tergantung pada kebutuhan setiap aplikasi.

Saya pikir apa pun yang terjadi, Anda ingin layanan Anda menerima token autentikasi yang disediakan oleh layanan otentikasi yang Anda tulis untuk memvalidasi pengguna. Ini adalah cara paling mudah / aman untuk mencegah penyalahgunaan layanan microser Anda. Juga, secara umum, jika Anda ingin klien memiliki pengalaman yang baik, Anda harus mengimplementasikan sendiri fitur-fitur penting dan menguji secara menyeluruh untuk memastikan bahwa fitur yang Anda tawarkan diimplementasikan dengan baik.

Karena semua penelepon perlu memberikan bukti layanan microser Anda bahwa mereka telah diautentikasi, Anda juga dapat mengikat izin untuk otentikasi tersebut. Jika Anda memberikan kemampuan untuk mengikat pengguna ke grup akses sewenang-wenang (atau grup jika Anda ingin menjadi mewah, meskipun izin tambah versus kurangi lebih sulit untuk ditangani di sini.), Akan ada lebih sedikit pertanyaan yang datang dari klien Anda tentang mengapa pengguna x dapat melakukan operasi yang tidak diinginkan. Dalam hal apa pun seseorang harus melakukan daftar akses untuk memeriksa setiap layanan, jadi mungkin Anda juga. Ini adalah sesuatu yang akan dengan mudah dikodekan pada awal semua layanan (if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }) Agar Anda dapat melakukannya dan melacak sendiri grup pengguna. Benar bahwa Anda harus memiliki manajer grup izin, dan memasukkannya ke dalam UI manajemen pengguna (gunakan grup baru yang sudah ada / buat izin pengguna). Sebutkan daftar pengguna yang terikat pada grup saat Anda mengedit definisi, untuk menghindari kebingungan . Tapi, itu bukan pekerjaan yang sulit. Hanya memiliki metadata untuk semua layanan, dan ikat mencari pemetaan antara kelompok dan layanan ke dalam penanganan token auth.

Ok, jadi ada beberapa detail, tetapi masing-masing klien Anda yang menginginkan fungsi ini harus membuat kode ini dalam hal apa pun, dan jika Anda mendukung izin pengguna tiga tingkat, Anda juga dapat memperpanjangnya menjadi per akses pengguna kelompok. Mungkin persimpangan logis antara izin grup dasar dan izin khusus pengguna akan menjadi agregasi yang tepat, tetapi jika Anda ingin dapat menambah dan menghapus izin dasar, dari Admin, Agen, izin basis pengguna akhir, Anda harus melakukan bendera tri-state ususal dalam grup izin: Tambahkan Izin, Tolak Izin, Izin Default dan menggabungkan izin dengan tepat.

(Sebagai catatan, ini semua harus terjadi pada sesuatu seperti SSL atau bahkan SSL dua arah jika Anda khawatir tentang keamanan dari kedua ujung percakapan. Jika Anda "membocorkan" token ini ke penyerang, dia seolah-olah dia ' d memecahkan kata sandi.)

Pandangan saya adalah Anda punya dua pilihan di sini.

• Jika Anda hanya perlu memiliki akses yang dapat dikonfigurasi pada dasarnya aplikasi yang sama, maka mintalah layanan memeriksa izin dan memberikan antarmuka kepada pelanggan Anda yang memungkinkan mereka untuk mengubah izin yang diberikan untuk setiap peran. Ini memungkinkan sebagian besar pengguna untuk menggunakan penyetelan peran default, di mana pelanggan 'masalah' dapat mengubah peran atau membuat yang baru sesuai dengan kebutuhan mereka.

• Jika pelanggan Anda mengembangkan aplikasi mereka sendiri, mereka harus memperkenalkan api perantara mereka sendiri. Yang terhubung dengan Anda sebagai admin, tetapi memeriksa permintaan yang masuk terhadap persyaratan auth custom mereka sendiri sebelum memanggil layanan Anda

Pertimbangan keamanan

Jika saya memahami dengan baik desain Anda, Anda bermaksud mendelegasikan beberapa mekanisme kontrol akses sumber daya ke sisi klien, yaitu aplikasi yang mengonsumsi mengurangi item yang dapat dilihat pengguna. Asumsi Anda adalah:

layanan mikro dan sistem otorisasi mereka tidak boleh diganggu dengan kebutuhan klien, karena mereka hanya konsumen dan bukan bagian dari sistem

Saya melihat di sini dua masalah serius untuk bisnis serius:

• Bagaimana jika beberapa pengguna jahat di luar sana (misalnya di salah satu pabrik mitra Anda) merekayasa balik aplikasi klien dan mencari tahu tentang API, mengelak dari pembatasan yang telah diterapkan perusahaannya pada klien dan menggunakan informasi itu untuk membahayakan perusahaan Anda? Perusahaan Anda akan mengklaim kerusakan, tetapi perusahaan parnter akan berpendapat bahwa Anda tidak memberikan sarana untuk melindungi data Anda dengan cukup baik.
• Biasanya, hanya masalah waktu bahwa data sensitif disalahgunakan (atau audit akan menemukan risikonya) dan manajemen Anda pada akhirnya akan meminta kontrol yang lebih ketat terhadap data tersebut.

Inilah sebabnya saya menyarankan untuk mengantisipasi peristiwa semacam itu dan mengurus permintaan otorisasi. Anda berada dalam fase rekayasa ulang awal dan akan jauh lebih mudah untuk mempertimbangkan ini dalam arsitektur Anda (bahkan jika Anda tidak menerapkan semuanya) daripada nanti.

Jika Anda mengejar posisi Anda saat ini, berkonsultasilah setidaknya dengan petugas keamanan informasi Anda.

Bagaimana cara mengimplementasikannya

Anda punya trik:

Dengan cara ini, kita harus melacak hanya token scope.

Oke, Anda bermaksud menggunakan beberapa token umum yang dipilih oleh klien. Lagi-lagi kelemahan di mata saya, karena beberapa klien bisa di luar kendali Anda.

Saya tidak tahu apakah Anda sudah menggunakan JWT atau jika Anda menggunakan beberapa teknik lain. Tetapi jika Anda menggunakan JWT, Anda dapat memiliki token identitas yang membawa identitas pengguna (dan bahkan token kedua yang mengidentifikasi aplikasi asal dengan aman, yang dapat memungkinkan Anda untuk membedakan tingkat kepercayaan antara klien internal dan klien eksternal ).

Ketika Anda berniat untuk pergi ke arsitektur microservice, saya ingin menyarankan untuk mengubah perbedaan antara manajemen pengguna dan proses otentikasi (yang harus dijalankan sebagai layanan khusus) dan kontrol akses (yang khusus untuk setiap microservice, dan harus ditangani secara lokal oleh masing-masing). Tentu saja beberapa klien admin harus memberikan tinjauan komprehensif di beberapa layanan, untuk kemudahan penggunaan).

Di sini, ada jawaban singkat juga. Anda harus menerapkan semua fitur inti yang ingin Anda tawarkan kepada "klien" Anda sendiri. Tampaknya bermasalah jika klien menambahkan perilaku mendasar seperti izin pengguna itu sendiri, karena Anda sudah melakukan otentikasi pengguna; jika Anda menyerahkannya kepada klien untuk mengimplementasikannya, Anda mungkin berakhir "mendukung" beberapa implementasi dari kode izin yang sama. Meskipun Anda tidak "memilikinya," akan ada bug dalam kode mereka dan Anda ingin klien Anda memiliki fungsi yang mereka harapkan, dengan alasan, sehingga Anda mendukung resolusi masalah yang dialami klien. Mendukung banyak basis kode tidak menyenangkan.