Autentikasi dan otorisasi di Azure Container Apps

  • Artikel

Azure Container Apps menyediakan fitur autentikasi dan otorisasi bawaan (terkadang disebut sebagai "Autentikasi Mudah"), untuk mengamankan aplikasi kontainer eksternal yang mendukung ingress eksternal dengan kode minimal atau tanpa kode.

Untuk detail seputar autentikasi dan otorisasi, lihat panduan berikut untuk pilihan penyedia Anda.

Mengapa menggunakan autentikasi bawaan?

Anda tidak diharuskan menggunakan fitur ini untuk autentikasi dan otorisasi. Anda dapat menggunakan fitur keamanan yang dipaket dalam kerangka kerja web pilihan Anda, atau Anda dapat menulis utilitas Anda sendiri. Namun, mengimplementasikan solusi aman untuk autentikasi (pengguna masuk) dan otorisasi (menyediakan akses ke data yang aman) dapat membutuhkan upaya yang signifikan. Anda harus memastikan untuk mengikuti praktik dan standar terbaik industri dan menjaga implementasi Anda tetap terbarui.

Fitur autentikasi bawaan untuk Container Apps menghemat waktu dan upaya Anda dengan menyediakan autentikasi siap pakai dengan penyedia identitas gabungan. Fitur-fitur ini memungkinkan Anda untuk lebih fokus pada pengembangan aplikasi Anda, dan lebih sedikit waktu untuk membangun sistem keamanan.

Manfaatnya mencakup:

  • Azure Container Apps menyediakan akses ke berbagai penyedia autentikasi bawaan.
  • Fitur autentikasi bawaan tidak memerlukan bahasa, SDK, keahlian keamanan, atau bahkan kode tertentu yang harus Anda tulis.
  • Anda dapat berintegrasi dengan beberapa penyedia termasuk ID Microsoft Entra, Facebook, Google, dan Twitter.

IdP

Container Apps menggunakan identitas federasi, yang memungkinkan penyedia identitas pihak ketiga mengelola identitas pengguna dan alur autentikasi untuk Anda. IdP berikut ini tersedia secara default:

Penyedia Titik akhir masuk Panduan cara kerja
Platform identitas Microsoft /.auth/login/aad Platform identitas Microsoft
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
Twitter /.auth/login/twitter Twitter
Semua penyedia OpenID Connect /.auth/login/<providerName> OpenID Connect

Saat Anda menggunakan salah satu penyedia ini, titik akhir masuk tersedia untuk autentikasi pengguna dan validasi token autentikasi dari penyedia. Anda dapat memberi pengguna Anda sejumlah opsi penyedia ini.

Pertimbangan untuk menggunakan autentikasi bawaan

Fitur ini harus digunakan hanya dengan HTTPS. Pastikan allowInsecure dinonaktifkan pada konfigurasi ingress aplikasi kontainer Anda.

Anda dapat mengonfigurasi aplikasi kontainer untuk autentikasi dengan atau tanpa membatasi akses ke API dan konten situs Anda. Untuk membatasi akses aplikasi hanya untuk pengguna yang diautentikasi, atur pengaturan Batasi akses ke Memerlukan autentikasi. Untuk mengautentikasi tetapi tidak membatasi akses, atur pengaturan Batasi akses ke Izinkan akses yang tidak diautentikasi.

Secara default, setiap aplikasi kontainer mengeluarkan cookie atau token uniknya sendiri untuk autentikasi. Anda juga dapat menyediakan kunci penandatanganan dan enkripsi Anda sendiri.

Arsitektur fitur

Komponen middleware autentikasi dan otorisasi adalah fitur platform yang berjalan sebagai kontainer sespan pada setiap replika di aplikasi Anda. Saat diaktifkan, aplikasi Anda menangani setiap permintaan HTTP masuk setelah melewati lapisan keamanan.

Diagram arsitektur yang menunjukkan permintaan yang dicegat oleh kontainer sidecar yang berinteraksi dengan penyedia identitas sebelum mengizinkan lalu lintas ke kontainer aplikasi

Platform middleware menangani beberapa hal untuk aplikasi Anda:

  • Mengautentikasi pengguna dan klien dengan idP yang ditentukan
  • Mengelola sesi terautentikasi
  • Masukkan informasi identitas ke header permintaan HTTP

Modul autentikasi dan otorisasi berjalan dalam kontainer terpisah, terisolasi dari kode aplikasi Anda. Karena kontainer keamanan tidak berjalan dalam proses, tidak ada integrasi langsung dengan kerangka kerja bahasa tertentu yang dimungkinkan. Namun, informasi relevan yang dibutuhkan aplikasi Anda disediakan di header permintaan seperti yang dijelaskan dalam artikel ini.

Alur autentikasi

Alur autentikasi sama untuk semua penyedia, tetapi berbeda tergantung pada apakah Anda ingin masuk dengan SDK penyedia:

  • Tanpa SDK penyedia (alur yang diarahkan server atau alur server): Aplikasi mendelegasikan proses masuk federasi ke Container Apps. Delegasi biasanya terjadi pada aplikasi browser, yang menyajikan halaman masuk penyedia kepada pengguna.

  • Dengan SDK penyedia (alur yang diarahkan klien atau alur klien): Aplikasi memasukkan pengguna ke penyedia secara manual lalu mengirim token autentikasi ke Container Apps untuk validasi. Pendekatan ini tipikal untuk aplikasi tanpa browser yang tidak menyajikan halaman masuk penyedia kepada pengguna. Contohnya adalah aplikasi seluler asli yang memasukkan pengguna menggunakan SDK penyedia.

Panggilan dari aplikasi browser tepercaya di Container Apps ke REST API lain di Container Apps dapat diautentikasi menggunakan alur yang diarahkan server. Untuk informasi selengkapnya, lihat Menyesuaikan masuk dan keluar.

Tabel memperlihatkan langkah-langkah alur autentikasi.

Langkah Tanpa penyedia SDK Dengan penyedia SDK
1. Masuk pengguna Mengalihkan klien ke /.auth/login/<PROVIDER>. Kode klien masuk pengguna langsung dengan SDK penyedia dan menerima token autentikasi. Untuk informasi, lihat dokumentasi penyedia.
2. Pasca-autentikasi Penyedia mengalihkan klien ke /.auth/login/<PROVIDER>/callback. Klien kode kirim token dari penyedia ke /.auth/login/<PROVIDER> untuk validasi.
3. Membuat sesi terautentikasi Container Apps menambahkan cookie yang diautentikasi ke respons. Container Apps mengembalikan token autentikasinya sendiri ke kode klien.
4. Menyajikan konten yang diautentikasi Klien menyertakan cookie autentikasi dalam permintaan berikutnya (ditangani secara otomatis oleh browser). Kode klien menyajikan token autentikasi di header X-ZUMO-AUTH.

Untuk browser klien, Container Apps dapat secara otomatis mengarahkan semua pengguna yang tidak diautentikasi ke /.auth/login/<PROVIDER>. Anda juga dapat menyajikan pengguna dengan satu atau beberapa /.auth/login/<PROVIDER> tautan untuk masuk ke aplikasi Anda menggunakan penyedia pilihan mereka.

Perilaku otorisasi

Dalam portal Azure, Anda dapat mengedit pengaturan autentikasi aplikasi kontainer untuk mengonfigurasinya dengan berbagai perilaku saat permintaan masuk tidak diautentikasi. Judul berikut ini menjelaskan opsi.

  • Izinkan permintaan yang tidak diautentikasi: Opsi ini menunda otorisasi lalu lintas yang tidak diautentikasi ke kode aplikasi Anda. Untuk permintaan yang diautentikasi, Container Apps juga meneruskan informasi autentikasi di header HTTP. Aplikasi Anda dapat menggunakan informasi di header untuk membuat keputusan otorisasi atas suatu permintaan.

    Opsi ini memberikan lebih banyak fleksibilitas dalam menangani permintaan anonim. Misalnya, ini memungkinkan Anda menyajikan beberapa penyedia masuk kepada pengguna Anda. Namun, Anda harus menulis kode.

  • Memerlukan autentikasi: Opsi ini akan menolak lalu lintas apa pun yang tidak diautentikasi ke aplikasi Anda. Penolakan ini dapat menjadi tindakan pengalihan ke salah satu penyedia identitas yang dikonfigurasi. Dalam kasus ini, klien browser dialihkan ke /.auth/login/<PROVIDER> penyedia yang Anda pilih. Jika permintaan anonim berasal dari aplikasi seluler asli, respons yang dikembalikan adalah HTTP 401 Unauthorized. Anda juga dapat mengonfigurasi penolakan menjadi HTTP 401 Unauthorized atau HTTP 403 Forbidden untuk semua permintaan.

    Dengan opsi ini, Anda tidak perlu menulis kode autentikasi apa pun di aplikasi Anda. Otorisasi yang lebih baik, seperti otorisasi khusus peran, dapat ditangani dengan memeriksa klaim pengguna (lihat Akses klaim pengguna).

    Perhatian

    Membatasi akses dengan cara ini berlaku untuk semua panggilan ke aplikasi Anda, yang mungkin tidak diinginkan untuk aplikasi yang menginginkan halaman beranda yang tersedia untuk umum, seperti dalam banyak aplikasi satu halaman.

    Catatan

    Secara default, setiap pengguna di penyewa Microsoft Entra Anda dapat meminta token untuk aplikasi Anda dari ID Microsoft Entra. Anda dapat mengonfigurasi aplikasi di MICROSOFT Entra ID jika Anda ingin membatasi akses ke aplikasi Anda ke sekumpulan pengguna yang ditentukan.

Mengkustomisasi rincian masuk dan keluar

Autentikasi Aplikasi Kontainer menyediakan titik akhir bawaan untuk masuk dan keluar. Saat fitur diaktifkan, titik akhir ini tersedia di bawah /.auth awalan rute pada aplikasi kontainer Anda.

Menggunakan banyak penyedia masuk

Konfigurasi portal tidak menawarkan cara turn-key untuk menyajikan beberapa penyedia masuk kepada pengguna Anda (seperti Facebook dan Twitter). Namun, tidak sulit untuk menambahkan fungsionalitas ke aplikasi Anda. Langkah-langkahnya diuraikan sebagai berikut:

Pertama, di halaman Autentikasi / Otorisasi di portal Azure, konfigurasikan setiap penyedia identitas yang ingin Anda aktifkan.

Dalam Tindakan yang diambil saat permintaan tidak diautentikasi, pilih Izinkan permintaan Anonim (tanpa tindakan).

Di halaman masuk, atau bilah navigasi, atau lokasi lain dari aplikasi Anda, tambahkan tautan masuk ke setiap penyedia yang Anda aktifkan ( /.auth/login/<provider> ). Contohnya:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/twitter">Log in with Twitter</a>

Saat pengguna memilih salah satu tautan, UI untuk masing-masing penyedia ditampilkan kepada pengguna.

Untuk mengalihkan pengguna pasca masuk ke URL kustom, gunakan post_login_redirect_uriparameter string kueri (tidak untuk disalahpahami dengan URI Pengalihan di konfigurasi penyedia identitas Anda). Misalnya, untuk menavigasi pengguna ke /Home/Index setelah masuk, gunakan kode HTML berikut:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Masuk yang diarahkan klien

Dalam proses masuk yang diarahkan klien, aplikasi memproses masuk pengguna ke penyedia identitas menggunakan SDK khusus penyedia. Kode aplikasi kemudian mengirimkan token autentikasi yang dihasilkan ke Container Apps untuk validasi (lihat Alur autentikasi) menggunakan permintaan HTTP POST.

Untuk memvalidasi token penyedia, aplikasi kontainer harus terlebih dahulu dikonfigurasi dengan penyedia yang diinginkan. Pada waktu proses, setelah Anda mengambil token autentikasi dari penyedia Anda, posting token ke /.auth/login/<provider> untuk validasi. Contohnya:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Format token sedikit bervariasi menurut penyedia. Untuk detailnya, lihat tabel berikut:

Nilai penyedia Diperlukan dalam badan permintaan Komentar
aad {"access_token":"<ACCESS_TOKEN>"} Properti id_token, refresh_token, dan expires_in bersifat opsional.
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} atau {"authentication_token": "<TOKEN>" authentication_token lebih disukai daripada access_token. Properti expires_in bersifat opsional.
Saat meminta token dari layanan Live, selalu minta ruang lingkup wl.basic.
google {"id_token":"<ID_TOKEN>"} Properti authorization_code bersifat opsional. Memberikan authorization_code nilai menambahkan token akses dan token refresh ke penyimpanan token. Ketika ditentukan, authorization_code juga dapat secara opsional disertai dengan properti redirect_uri.
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Gunakan token akses pengguna yang valid dari Facebook.
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}

Jika token penyedia berhasil divalidasi, API akan kembali dengan authenticationToken dalam isi respons, yang merupakan token sesi Anda.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Setelah Anda memiliki token sesi ini, Anda dapat mengakses sumber daya aplikasi yang dilindungi dengan menambahkan header X-ZUMO-AUTH ke permintaan HTTP Anda. Contohnya:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Keluar dari sesi

Pengguna dapat keluar dengan mengirim GET permintaan ke titik akhir aplikasi /.auth/logout . Permintaan GET melakukan tindakan berikut:

  • Menghapus cookie autentikasi dari sesi saat ini.
  • Menghapus token pengguna saat ini dari penyimpanan token.
  • Melakukan keluar sisi server di idP untuk ID Microsoft Entra dan Google.

Berikut adalah tautan keluar sederhana di halaman web:

<a href="/.auth/logout">Sign out</a>

Secara default, keluar yang berhasil mengalihkan klien ke URL /.auth/logout/done. Anda bisa mengubah halaman pengalihan pasca-keluar dengan menambahkan parameter kueri post_logout_redirect_uri. Contohnya:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Pastikan untuk mengodekanpost_logout_redirect_urinilai .

URL harus dihosting di domain yang sama saat menggunakan URL yang sepenuhnya memenuhi syarat.

Mengakses klaim pengguna dalam kode aplikasi

Untuk semua kerangka kerja bahasa, Container Apps membuat klaim dalam token masuk tersedia untuk kode aplikasi Anda. Klaim dimasukkan ke header permintaan, yang ada baik dari pengguna akhir yang diautentikasi atau aplikasi klien. Permintaan eksternal tidak diizinkan untuk mengatur header ini, sehingga hanya disajikan jika diatur oleh Container Apps. Beberapa contoh header meliputi:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

Kode yang ditulis dalam bahasa atau kerangka kerja apa pun bisa mendapat informasi yang dibutuhkan dari header ini.

Catatan

Kerangka kerja bahasa yang berbeda mungkin menampilkan {i>header

Langkah berikutnya

Lihat artikel berikut untuk detail tentang mengamankan aplikasi kontainer Anda.