Autentikasi dan otorisasi di aplikasi
Keamanan sangat penting untuk aplikasi web modern. Fluid Framework, sebagai bagian dari arsitektur aplikasi web Anda adalah bagian penting dari infrastruktur untuk diamankan. Fluid Framework adalah arsitektur berlapis, dan konsep yang berhubungan dengan autentikasi diimplementasikan berdasarkan layanan Fluid yang terhubung dengannya. Ini berarti bahwa, meskipun ada tema autentikasi umum di semua layanan Fluid, rincian dan spesifikasinya akan berbeda untuk setiap layanan.
Layanan Azure Fluid Relay
Setiap penyewa layanan Azure Fluid Relay yang Anda buat diberi ID penyewa dan kunci rahasia penyewa uniknya sendiri.
Kunci rahasia merupakan rahasia bersama. Aplikasi/layanan Anda mengetahuinya, dan layanan Azure Fluid Relay mengetahuinya. Karena kunci rahasia penyewa terikat secara unik dengan penyewa Anda, menggunakannya untuk menandatangani jaminan permintaan ke layanan Azure Fluid Relay bahwa permintaan tersebut berasal dari pengguna resmi penyewa.
Kunci rahasia adalah bagaimana layanan Azure Fluid Relay tahu bahwa permintaan berasal dari aplikasi atau layanan Anda. Ini sangat penting, karena begitu layanan Azure Fluid Relay dapat mempercayai bahwa aplikasi Anda membuat permintaan, ia dapat mempercayai data yang Anda kirim. Inilah juga pentingnya mengapa rahasia harus ditangani dengan aman.
Perhatian
Siapa pun yang memiliki akses ke rahasia dapat meniru aplikasi Anda saat berkomunikasi dengan layanan Azure Fluid Relay.
JSON Web Token dan Layanan Azure Fluid Relay
Azure Fluid Relay menggunakan JSON Web Token (JWT) untuk menyandikan dan memverifikasi data yang ditandatangani dengan kunci rahasia Anda. JSON Web Token adalah bagian yang ditandatangani dari JSON yang dapat mencakup informasi tambahan tentang hak dan izin.
Catatan
Spesifikasi JWT berada di luar lingkup artikel ini. Untuk informasi selengkapnya tentang standar JWT, lihat Pengenalan Token Web JSON.
Meskipun rincian autentikasi berbeda antara layanan Fluid, beberapa nilai harus selalu ada.
- containerId Layanan Fluid membutuhkan ID kontainer untuk mengidentifikasi layanan mana yang sesuai dengan kontainer panggilan. Catatan: JWT memanggil bidang ini documentId, tetapi layanan Fluid memerlukan ID kontainer di bidang ini.
- tenantId: Layanan Azure Fluid Relay menggunakan ID penyewa untuk mengambil rahasia bersama yang akan digunakan untuk mengautentikasi permintaan Anda.
- lingkup: Lingkup menentukan izin kontainer panggilan. Isi bidang lingkup fleksibel, memungkinkan Anda untuk membuat izin kustom Anda sendiri.
{
"alg": "HS256",
"typ": "JWT"
}.{
"documentId": "azureFluidDocumentId",
"scopes": [ "doc:read", "doc:write", "summary:write" ],
"user": {
"name": "TestUser",
"id": "Test-Id-123"
},
"iat": 1599098963,
"exp": 1599098963,
"tenantId": "AzureFluidTenantId",
"ver": "1.0"
}.[Signature]
Mode pengguna menunjukkan apakah koneksi dalam mode baca atau baca/tulis. Hal ini dapat dilihat dari connections
lapangan di AzureAudience
. Izin lingkup token dapat diperbarui di Fungsi Azure tanpa server Anda di bawah fungsi generateToken
.
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
Ruang lingkup token bersama dengan perilaku dan mode kontainer adalah sebagai berikut:
Cakupan token | Perilaku Dokumen Saya | Perilaku Dokumen Pemirsa |
---|---|---|
DocRead | Baca dan tulis ke dokumen. Perubahan yang dilakukan pada dokumen tidak tercermin dalam dokumen audiens lainnya. Mode: Baca |
Baca dan tulis ke dokumen. Perubahan tidak tercermin dalam dokumen audiens lainnya. Mode: Tulis |
DocWrite | Baca dan tulis ke dokumen. Perubahan yang dilakukan tercermin dalam semua dokumen audiens lainnya. Mode: Tulis |
Baca dan tulis ke dokumen. Perubahan yang dilakukan tercermin dalam semua dokumen audiens lainnya. Mode: Tulis |
DocRead, DocWrite | Baca dan tulis ke dokumen. Perubahan yang dilakukan tercermin dalam semua dokumen audiens lainnya. Mode: Tulis |
Baca dan tulis ke dokumen. Perubahan yang dilakukan tercermin dalam semua dokumen audiens lainnya. Mode: Tulis |
Catatan
Perhatikan bahwa token juga menyertakan informasi pengguna (lihat baris 7-9 di atas). Anda dapat menggunakan ini untuk menambah informasi pengguna yang secara otomatis tersedia untuk kode Fluid menggunakan fitur audiens. Lihat Menambahkan data kustom ke token untuk informasi selengkapnya.
Penyedia token
Setiap permintaan ke Azure Fluid Relay harus ditandatangani dengan JWT yang valid. Fluid mendelegasikan tanggung jawab untuk membuat dan menandatangani token ini ke penyedia token.
Penyedia token bertanggung jawab untuk membuat dan menandatangani token yang @fluidframework/azure-client
gunakan untuk membuat permintaan ke layanan Azure Fluid Relay. Anda harus menyediakan implementasi penyedia token aman Anda sendiri. Namun, Fluid menyediakan InsecureTokenProvider
yang menerima rahasia penyewa Anda, kemudian secara lokal menghasilkan dan mengembalikan token yang ditandatangani. Penyedia token ini berguna untuk pengujian, tetapi tidak dapat digunakan dalam skenario produksi.
Penyedia token tanpa server yang aman
Satu opsi untuk membuat penyedia token yang aman adalah membuat Fungsi Azure tanpa server dan mengeksposnya sebagai penyedia token. Hal ini memungkinkan Anda untuk menyimpan kunci rahasia penyewa pada server yang aman. Aplikasi Anda kemudian akan memanggil Azure Function untuk menghasilkan token dibandingkan menandatanganinya secara lokal seperti yang dilakukan InsecureTokenProvider
. Untuk informasi selengkapnya, lihat Panduan cara kerja: Menulis TokenProvider dengan Azure Function.
Menghubungkan autentikasi pengguna ke autentikasi layanan Fluid
Layanan Fluid mengautentikasi panggilan masuk menggunakan rahasia klien bersama, yang tidak terkait dengan pengguna tertentu. Autentikasi pengguna dapat ditambahkan berdasarkan rincian layanan Fluid Anda.
Salah satu opsi sederhana untuk autentikasi pengguna adalah dengan menggunakan Azure Function sebagai penyedia token Anda, dan memberlakukan autentikasi pengguna sebagai syarat untuk mendapatkan token. Jika aplikasi mencoba untuk memanggil Fungsi maka akan gagal kecuali diautentikasi dengan sistem autentikasi Anda. Jika Anda menggunakan ID Microsoft Entra, misalnya, Anda dapat membuat aplikasi Microsoft Entra untuk Azure Function Anda, dan mengikatnya ke sistem autentikasi organisasi Anda.
Dalam hal ini pengguna akan masuk ke aplikasi Anda menggunakan ID Microsoft Entra, di mana Anda akan mendapatkan token untuk digunakan untuk memanggil Azure Function Anda. Fungsi Azure itu sendiri berulah sama, tetapi sekarang hanya dapat diakses oleh orang-orang yang juga telah mengautentikasi dengan ID Microsoft Entra.
Karena Fungsi Azure sekarang menjadi titik masuk Anda untuk mendapatkan token yang valid, hanya pengguna yang telah diautentikasi dengan benar ke Function kemudian akan dapat memberikan token itu ke layanan Azure Fluid Relay dari aplikasi klien mereka. Pendekatan dua langkah ini memungkinkan Anda untuk menggunakan proses autentikasi kustom Anda sendiri bersama dengan layanan Azure Fluid Relay.