Menjinakkan protokol kepercayaan - OAuth otentikasi dengan InterSystems IRIS

Bagaimana memungkinkan komputer saling mempercayai ketidakhadiran Anda, sambil menjaga keamanan dan privasi?



- Martini kering. Dalam gelas besar.
- Oui, tuan. [Ya, Monsieur (Fr.)]
"Sebentar, tidak semua." Tiga jari Gordon, satu vodka, setengah jari Kina Lyklet. Kocok dengan baik dalam shaker, dan kemudian masukkan sepotong besar lemon. Apakah kamu ingat?

Jan Fleming, Casino Royale, 1953

Bagian 1. OAuth 2.0 dan OpenID Connect Stories

Universal dan, tampaknya, hari ini di abad ke-21, sekelompok delegasi akses terbuka dan protokol otentikasi favorit semua orang disebut OAuth + OIDC. Lebih baik untuk penggunaan massal, mereka belum membuat apa pun. Mereka sangat populer dengan vendor front-end karena mereka berjalan di atas protokol HTTP (S) dan menggunakan wadah JWT ( JSON Web Token ). OpenID Connect menggunakan OAuth untuk pekerjaannya atau, dengan kata lain, OIDC adalah pembungkus untuk OAuth.

OpenID - standar terbuka untuk otentikasi dan pembuatan sistem identifikasi digital bukanlah hal baru bagi pengembang. Tahun ini, dia berusia 14 tahun. Dalam versi ketiga saat ini, nama lengkapnya adalah OpenID Connect atau lebih pendek dari OIDC. Ini populer baik dalam pengembangan web dan seluler, dan dalam sistem perusahaan.

Rekannya, Standar Delegasi Akses Terbuka OAuth, berusia 12 tahun. Dan 9 tahun sejak standar RFC 5849 yang sesuai muncul. Kami akan mengandalkan versi modern dari protokol OAuth 2.0 dan RFC 6749 saat ini. Ingatlah bahwa OAuth 2.0 tidak kompatibel dengan pendahulunya OAuth 1.0.

OAuth - protokol terbuka (skema, transportasi) untuk mendelegasikan akses, yang memungkinkan menyediakan akses terbatas kepada pihak ketiga ke sumber daya yang dilindungi pengguna tanpa perlu mentransfer ke mereka (pihak ketiga) login dan kata sandi RFC 6749

oauth.net adalah situs web OAuth terkemuka yang diselenggarakan oleh Aaron Parecki

oauth.com - Tutorial OAuth dan Lingkungan Uji

Open ID Connect (OIDC) adalah standar terbuka untuk sistem identifikasi terdesentralisasi yang memungkinkan pengguna untuk membuat satu akun untuk identifikasi pada berbagai sumber daya Internet yang tidak terkait menggunakan layanan pihak ketiga, menggunakan pesan OAuth dan wadah JWT untuk komunikasi yang aman.

Sebenarnya, OAuth bukan protokol, tetapi seperangkat aturan (skema) untuk memisahkan dan mentransfer operasi identifikasi pengguna ke server tepercaya saat menerapkan arsitektur pembatasan akses kontrol dalam sistem perangkat lunak.

Dan, perhatian, OAuth tidak bisa mengatakan apa-apa tentang pengguna tertentu ! Baik siapa dia, atau di mana dia sekarang, atau bahkan apakah dia bekerja di depan komputer sekarang atau tidak. Tetapi kemudian memungkinkan untuk berinteraksi dengan sistem tanpa campur tangan pengguna, menggunakan token akses yang sudah dikeluarkan. Ini poin penting.

Ini mungkin berguna:

• OAuth menggabungkan dengan sempurna dengan penggunaan bahasa deskripsi akses atribut XACML
• OAuth juga mengandalkan Akses yang Dikelola Pengguna ( UMA )

Penggunaan bersama OAuth + OIDC + UMA memungkinkan penerapan sistem identifikasi dan kontrol akses yang aman (Identity and Access Management - IdM, IAM) di berbagai area subjek, misalnya:

• menggunakan profil HEART (Health Relationship Trust) dari data pribadi pasien dalam kedokteran
• pada platform identifikasi pelanggan CIAM (Identitas Konsumen dan Akses) untuk perusahaan manufaktur dan perdagangan
• personalisasi sertifikat digital perangkat pintar dalam sistem IoT (Internet of Things)

Venn Baru Untuk Kontrol Akses Untuk Ekonomi API

Yang terpenting, jangan menyimpan data pribadi di tempat yang sama dengan sistem lainnya. Pisahkan otentikasi dan otorisasi secara fisik. Dan bahkan lebih baik - berikan semua identifikasi secara pribadi kepada orang tersebut dan jangan pernah menyimpannya bersama Anda. Percayai pemilik perangkat.

Apple mengatakan apa yang disimpan data pribadi Rusia di Rusia. Ini adalah nama, alamat, email, nomor telepon. Tapi Pesan, foto, dll. Orang-orang itu sendiri mempercayai cloud iCloud (yang bukan di Rusia).

Bagian 2. Main pendek "Kepercayaan dan Otentikasi"

Jadi, kami memutuskan bahwa tidak aman untuk menyimpan data pribadi pengguna terkasih baik dalam aplikasi kami, maupun dalam penyimpanan tunggal bersama dengan database yang berfungsi. Artinya, mereka telah memilih wali amanat yang dapat diandalkan yang akan memberikan layanan ini kepada kami. Maka, ketika Yang Mulia Pengguna muncul, maka kami menyediakan dialog berikut.

Aktor:

• Pengguna
• Aplikasi Klien
• Layanan Identitas
• Server Sumber Daya

Tindakan terjadi di browser di komputer pengguna. Semua karakter telah lama akrab satu sama lain. Pengguna memiliki akun pribadi di Layanan Identitas. Aplikasi Klien memiliki kontrak yang ditandatangani dan ditandatangani dengan Layanan Identifikasi dan antarmuka timbal balik. Server Sumber Daya mempercayai Layanan Identitas dalam masalah mengeluarkan kunci akses untuk setiap penderita yang dapat diidentifikasi.

Pengguna (P): (dengan meluncurkan aplikasi klien berbasis web) Aplikasi Klien yang terhormat, saya membutuhkan "sumber daya ini".
Aplikasi klien (K): Pengguna yang terhormat, pertama-tama berikan kunci untuk "sumber daya ini". Tanpa kunci, akses ke "sumber daya ini" ditutup.
P: Saya tidak punya kunci seperti itu.
K: Maka saya akan sementara waktu mengalihkan Anda ke layanan identifikasi yang dengannya kami memiliki perjanjian untuk mengeluarkan kunci ke Server Sumber Daya. (mengalihkan P. ke layanan identifikasi)
Layanan Identifikasi (I): Pengguna yang terhormat, tolong beri tahu saya siapa Anda dan kunci apa yang Anda butuhkan?
P: Saya, Pengguna Pengguna Ytsuken, kata sandinya seperti ini dan itu, saya ingin mendapatkan akses ke "sumber daya ini".
Dan: Terima kasih, kawan Jtsuken. Otentikasi berhasil dan identifikasi Anda diverifikasi. Ini adalah kunci untuk "sumber daya ini" (P. pengalihan kembali ke K.)
P: Klien, saya membawakan Anda kunci ke "sumber daya" yang saya butuhkan.
K: Pengguna terima kasih. Kuncinya benar. Inilah "sumber daya" yang Anda minta.

Tirai. Simfoni pembuka Richard Strauss dari film "Space Odyssey of 2001" diputar

Bagian 3. Layanan otorisasi nyata

Sekarang mari kita mulai bisnis. Kami memiliki tiga tugas dalam agenda: untuk menunjuk karakter, mempersiapkan panggung dan memainkan permainan. Dan semuanya diputuskan sekaligus pada platform IRIS InterSystems. Tapi ini tidak perlu, Anda dapat merakit desain dari platform yang berbeda atas kebijakan Anda. Misalnya, dalam kombinasi ini: OAuth Keycloak server + OAuth client dan sumber daya OAuth di IRIS. Dengan kata lain:

1. Konfigurasikan dan luncurkan server OAuth dengan registrasi klien demo kami.
2. Siapkan klien demo OAuth dengan menghubungkannya ke server OAuth dan sumber daya web.
3. Kembangkan aplikasi klien yang dapat menggunakan OAuth. Anda dapat menggunakan Java, Python, C #, NodeJS. Berikut ini adalah contoh kode aplikasi dalam ObjectScript.

Situs web komunitas pengembang memiliki instruksi terperinci oleh Daniel Kutak dalam tiga bagian dengan contoh penggunaan OAuth dalam IRIS untuk berbagai aplikasi berdasarkan CSP ( bagian 1 , bagian 2 , bagian 3 ).

Ada banyak pengaturan di OAuth. Karena itu, tulis sendiri daftar periksa - ini adalah aplikasi yang paling benar untuk mereka. Contoh dan kosong di bawah.

Di mana mendapatkan IRIS InterSystems yang sudah jadi untuk sampel? Setidaknya ada dua opsi yang tersedia untuk semua orang:

Dapatkan server cloud IRIS yang sudah disiapkan sebelumnya pada platform pelatihan Layanan Pembelajaran InterSystems di bagian Lab Pembelajaran InterSystems.

Pasang wadah buruh pelabuhan yang sudah jadi . Baca selengkapnya di artikel - instruksi langkah demi langkah untuk pemula Meluncurkan IRIS Menggunakan pengembang Docker atau, yang lebih suka video, instruksi screencast dari Mengembangkan Solusi dengan Antar Sistem IRIS Menggunakan Docker dan VSCode

1-1 Mengkonfigurasi Server OAuth

Kami masuk ke portal manajemen IRIS dan pilih bagian:

Administrasi Sistem >> Keamanan >> OAuth 2.0 >> Server

Selanjutnya, dalam setiap paragraf, akan ada nama untuk baris pengaturan dan, melalui titik dua, contoh atau penjelasan, jika perlu.



Tab Pengaturan Umum:
Deskripsi: opsional, misalnya, jadi "Server otorisasi"
Titik akhir generator (selanjutnya disebut CTG) adalah nama host: nama DNS server Anda
Jenis izin yang didukung (pilih setidaknya satu):
Kode Otorisasi
Tersirat
Kredensial: sumber daya, pemilik, kata sandi
Kredensial pelanggan
Konfigurasi SSL / TLS: oauthserver

Tab izin:
tambahkan volume yang didukung: mis. scope1 dan scope2

Tab interval:
Interval Kunci Akses: 3600
Interval Kode Otorisasi: 60
Perbarui Interval Kunci: 86400
Interval Sesi Interupsi: 86400
Periode Validitas Kunci Klien: 0

Tab Pengaturan JWT:
Algoritma Input: RS512
Algoritma Manajemen Kunci: RSA-OAEP
Algoritma Enkripsi Konten: A256CBC-HS512

Menyesuaikan tab:
Identifikasi kelas:% OAuth2.Server.Authenticate
Periksa kelas pengguna:% OAuth2.Server.Validate
Kelas Layanan Sesi: OAuth2.Server.Session
Hasilkan kelas kunci:% OAuth2.Server.JWT
Namespace Kustomisasi:% SYS
Peran penyesuaian (pilih setidaknya satu):% DB_IRISSYS dan% Manager

Simpan.

1-2 Daftarkan klien di server OAuth

Tombol Deskripsi Pelanggan >> Tombol Buat Deskripsi Pelanggan:

Tab Pengaturan Umum:
Nama: KLIEN
Deskripsi: sewenang-wenang
Jenis Klien: Rahasia
Redirect URLs: Alamat titik balik di aplikasi kami setelah otentikasi
Jenis Izin yang Didukung
Kode Otorisasi: ya
Tersirat
Kredensial: sumber daya, pemilik, kata sandi
Kredensial pelanggan
Otorisasi JWT
Jenis Jawaban yang Didukung
kode
id_token
kunci id_token
token
Jenis Otorisasi: Sederhana

Tab Kredensial Klien: Diisi Secara Otomatis

Tab Informasi Klien:
URL peluncuran:
Layar masuk
Nama pelanggan
URL logo
URL Halaman Beranda Klien
URL kebijakan
Ketentuan URL Layanan

2-1 Mengonfigurasi pengikatan pada klien server OAuth

Administrasi Sistem >> Keamanan >> OAuth 2.0 >> Klien



Buat deskripsi server:
Titik akhir generator: ambil dari parameter server umum, lihat di atas
Konfigurasi SSL / TLS: pilih dari daftar pra-konfigurasi

Isi dari kolom yang tersisa akan diunduh secara otomatis dari server, tetapi Anda juga dapat mengonfigurasinya secara manual:

Server otorisasi
Titik Akhir Otorisasi: CTG + / otorisasi
Titik Akhir Kunci: CTG + / token
Informasi Pengguna Endpoint: CTG + / userinfo
Titik akhir diagnosis mandiri utama: CTG + / pencabutan
Titik akhir pencabutan kunci: CTG + / introspeksi
Pengaturan Token Web JSON (JWT)
Sumber lain selain pendaftaran dinamis: pilih JWKS dari URL
URL: CTG + / jwks



Dari daftar ini, misalnya, dapat dilihat (scopes_supported dan claim_supported) bahwa server dapat memberikan klien OAuth informasi berbeda tentang pengguna. Dan perlu diperhatikan bahwa saat mengimplementasikan aplikasi Anda, Anda perlu bertanya kepada pengguna data apa yang siap ia bagikan. Selanjutnya, dalam contoh kita, kita hanya akan dimintai izin oleh scope1.

Simpan.

Jika ada kesalahan yang menunjukkan SSL, maka pergi ke pengaturan:
Administrasi Sistem >> Keamanan >> Konfigurasi SSL / TSL

2-2 Mengkonfigurasi Klien OAuth

Administrasi Sistem >> Keamanan >> OAuth 2.0 >> Klien >> Konfigurasi Klien >> Buat Konfigurasi Klien



Tab umum:
Nama Aplikasi: klien demo
Nama Klien: klien demo
Keterangan: opsional
Diaktifkan: Ya
Jenis Klien: Rahasia
Konfigurasi SSL / TCL: oauthclient
URL pengalihan klien: Nama DNS server Anda
Jenis Izin yang Diperlukan
Kode Otorisasi: ya
Tersirat
Kredensial: sumber daya, pemilik, kata sandi
Kredensial pelanggan
Otorisasi JWT
Jenis Otorisasi: Sederhana

Tab Informasi Klien:
Layar masuk
URL logo
URL Halaman Beranda Klien
URL kebijakan
Ketentuan URL Layanan
Volume default: kami ambil dari yang ditentukan sebelumnya di server, misalnya, scope1
Alamat email kontak (dipisahkan dengan koma)
Usia default maksimum (dalam detik)

Tab Pengaturan JWT:
Pengaturan Token Web JSON (JWT)
Membuat Pengaturan JWT dari Kredensial X509
Algoritma IDToken
Penandatanganan: RS256
Enkripsi: A256CBC
Kunci: RSA-OAEP
Algoritma Userinfo
Algoritma Token Akses
Algoritma Permintaan

Tab Kredensial Klien:
Id klien: dari yang dikeluarkan saat pendaftaran klien di server (lihat di atas)
ID pelanggan dikeluarkan
Rahasia klien: dari yang dikeluarkan saat mendaftarkan klien di server (lihat di atas)
Rahasia klien kedaluwarsa
Registrasi Pelanggan URI

Simpan.

Bagian 4. Kode

Mari kita buat aplikasi web minimalis dengan otorisasi OAuth dan REST.

Ketika bekerja, OAuth bergantung pada kenyataan bahwa saluran komunikasi antara peserta dalam interaksi (server, klien, aplikasi web, browser pengguna, server sumber daya) entah bagaimana dilindungi. Paling sering, peran ini dimainkan oleh SSL / TLS. Tetapi OAuth juga akan bekerja pada saluran yang tidak aman. Sebagai contoh, server Keycloak, secara default, menggunakan protokol HTTP dan berjalan tanpa perlindungan. Ini menyederhanakan pengembangan dan debugging selama pengembangan. Dengan penggunaan nyata layanan OAuth, perlindungan saluran harus benar-benar diaktifkan - ini dicatat dalam dokumentasi Keycloak. InterSystems Pengembang IRIS mengambil pendekatan yang lebih ketat untuk OAuth - SSL / TSL diperlukan. Satu-satunya penyederhanaan adalah bahwa Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau menggunakan layanan PKI yang dibangun ke IRIS (Administrasi Sistem >> Keamanan >> Sistem Kunci Publik).

Otorisasi pengguna diperiksa dengan indikasi eksplisit dari dua parameter - nama aplikasi Anda dan volume yang didukung oleh server OAuth dan di klien OAuth (ruang lingkup - Saya ingin tahu bagaimana cara menyebutkannya dengan benar dalam bahasa Rusia?):

Parameter OAUTH2APPNAME = "OAuthClient"; set isAuthorized = ##class(%SYS.OAuth2.AccessToken).IsAuthorized( ..#OAUTH2APPNAME, .sessionId, "scope1", .accessToken, .idtoken, .responseProperties, .error) 

Dengan tidak adanya otorisasi, kami sedang menyiapkan tautan ke permintaan untuk identifikasi pengguna dan mendapatkan izin darinya untuk bekerja dengan aplikasi kami. Di sini kita perlu menunjukkan tidak hanya nama aplikasi dan volume yang diminta (lingkup) yang terdaftar di server OAuth dan di klien OAuth, tetapi juga tautan balik ke titik mana aplikasi web harus mengembalikan pengguna.

 Parameter OAUTH2CLIENTREDIRECTURI = "https://52773b-76230063.labs.learning.intersystems.com/oauthclient/" set url = ##class(%SYS.OAuth2.Authorization).GetAuthorizationCodeEndpoint( ..#OAUTH2APPNAME, "scope1", ..#OAUTH2CLIENTREDIRECTURI, .properties, .isAuthorized, .sc) 

Kami menggunakan layanan otentikasi IRIS bawaan dan, oleh karena itu, kami mendaftarkan pengguna di server IRIS OAuth. Sebagai contoh, cukup untuk menetapkan pengguna hanya nama pengguna dan kata sandi, Anda tidak perlu membuat pengaturan lain di akun.

Saat mentransfer pengguna menggunakan tautan yang diterima, server akan melakukan prosedur identifikasi pengguna dan meminta izin darinya untuk beroperasi dengan kredensial di aplikasi web, dan juga menyimpan hasilnya di OAuth2.Server.Session global di area% SYS:





3. Tunjukkan data pengguna yang sah. Setelah berhasil menyelesaikan prosedur, kami memiliki, misalnya, token akses. Mari kita mendapatkannya:

 set valid = ##class(%SYS.OAuth2.Validation).ValidateJWT( .#OAUTH2APPNAME, accessToken, "scope1", .aud, .JWTJsonObject, .securityParameters, .sc ) 

Jika perlu, aktifkan pesan debug yang diperluas pada server OAuth dan klien OAuth. Pesan ditulis ke ISCLOG global di area% SYS. Ketik terminal IRIS Anda (atau instal dan gunakan terminal web ):

 set ^%ISCLOG = 5 set ^%ISCLOG("Category", "OAuth2") = 5 set ^%ISCLOG("Category", "OAuth2Server") = 5 

Lihat dokumentasi IRIS Menggunakan OAuth 2.0 dan OpenID Connect untuk informasi lebih lanjut .

Kesimpulan:

1. OAuth membantu layanan yang terpisah secara fisik dan geografis dengan kredensial pengguna dan database "yang berfungsi". Dan, dengan demikian, memperkuat perlindungan data identifikasi dan, jika perlu, mematuhi persyaratan undang-undang tentang perlindungan data pribadi berbagai negara.
2. Dengan menggunakan OAuth, pengguna dapat diberi kesempatan untuk bekerja dengan aman dari banyak perangkat pada saat yang bersamaan dan "menyinari" data pribadinya secara minimal ke berbagai layanan dan aplikasi. Selain tidak mengambil informasi "berlebihan" tentang pengguna di layanan mereka, yaitu untuk melakukan pemrosesan data yang direpersonalisasikan dalam layanan mereka.
3. Saat menggunakan InterSystems IRIS, Anda memiliki satu set lengkap alat yang siap pakai untuk menguji dan menggunakan layanan OAuth dan OIDC, keduanya berdiri sendiri dan bekerja sama dengan produk perangkat lunak pihak ketiga.

Industri apa yang paling umum menggunakan platform IRIS InterSystems?
Untuk otomatisasi kesehatan, di sektor keuangan, untuk proyek-proyek e-government, logistik, ritel, dan banyak industri lainnya.

Jika Anda tertarik pada tugas-tugas otomatisasi kesehatan, maka perhatikan standar FHIR. InterSystems IRIS for Health (versi khusus dari platform IRIS InterSystems) memiliki dukungan untuk standar FHIR untuk integrasi dan pengembangan aplikasi

Seperti yang Anda lihat di atas, semua fitur OAuth mudah diakses dan sepenuhnya siap digunakan. Jika perlu, Anda dapat mengganti kelas handler dan antarmuka pengguna dengan kelas Anda sendiri. Pengaturan server dan klien OAuth dapat dibuat dari file konfigurasi, alih-alih menggunakan portal manajemen.