Autentikasi (HTTP Server API)

Beberapa aplikasi server memerlukan autentikasi klien untuk mengakses sumber daya dan permintaan HTTP layanan. Dimulai dengan versi 2.0, HTTP Server API melakukan autentikasi sisi server untuk aplikasi. Dalam HTTP Server API versi 1.0, aplikasi server harus menerapkan autentikasinya sendiri. Beberapa keuntungan autentikasi yang dilakukan oleh HTTP Server API meliputi:

  • Aplikasi dapat berjalan di bawah hak istimewa rendah, sehingga mengurangi risiko keamanan.
  • Autentikasi dilakukan dalam mode kernel, sehingga mengurangi transisi dari mode pengguna ke mode kernel selama autentikasi.
  • Autentikasi yang dilakukan dalam mode kernel memungkinkan aplikasi server berjalan pada akun pengguna yang berbeda. Di versi 1.0, semua aplikasi pada komputer harus berjalan di bawah akun pengguna yang sama untuk mengautentikasi pada Nama Prinsip Layanan (SPN).
  • Jabat tangan autentikasi NTLM tidak diatur ulang jika proses pekerja didaur ulang saat jabat tangan sedang dalam proses.

Untuk memanfaatkan autentikasi versi 2.0, aplikasi memungkinkan skema autentikasi yang diterapkan API SERVER HTTP ke URL yang telah didaftarkan aplikasi. Autentikasi dapat diaktifkan pada sesi server atau grup URL. Grup URL mewarisi skema autentikasi yang diaktifkan oleh sesi server jika tidak ada yang diatur pada grup URL. HTTP Server API mendukung skema berikut:

  • Negosiasi
  • NTLM
  • digest
  • Dasar

Aplikasi server juga dapat menerapkan skema autentikasi yang tidak didukung oleh HTTP Server API. HTTP Server API mengirimkan permintaan ke aplikasi untuk skema autentikasi yang tidak didukung, atau untuk skema yang belum diaktifkan oleh aplikasi.

Mengaktifkan Autentikasi

Aplikasi server mengaktifkan dan mengonfigurasi autentikasi pada sesi server atau grup URL dengan fungsi HttpSetServerSessionProperty atau HttpSetUrlGroupProperty sebagai berikut:

  1. Aplikasi ini mengaktifkan autentikasi dengan menentukan HttpServerAuthenticationProperty dalam parameter PropertiHttpSetServerSessionProperty atau HttpSetUrlGroupProperty.
  2. Aplikasi menentukan parameter konfigurasi dalam struktur HTTP_SERVER_AUTHENTICATION_INFO dalam parameter pPropertyInformation dari HttpSetServerSessionProperty atau HttpSetUrlGroupProperty. Aplikasi menentukan skema autentikasi yang diaktifkan, apakah penembolokan kredensial NTLM dinonaktifkan, dan memasok parameter Dasar dan Hash dalam struktur HTTP_SERVER_AUTHENTICATION_INFO .

Prosedur Autentikasi

Untuk memulai autentikasi Server HTTP, aplikasi mengaktifkan properti autentikasi sebelum permintaan pertama tiba pada antrean permintaan. Langkah-langkah berikut adalah alur pemrosesan umum untuk mengautentikasi permintaan.

  1. Aplikasi mengaktifkan autentikasi. Lihat bagian "Mengaktifkan Autentikasi" sebelumnya.

    Catatan

    Klien mengirimkan permintaan yang tidak diaauthenticated. HTTP Server API meneruskan permintaan ke aplikasi server dan memungkinkannya untuk menghasilkan tantangan 401 awal. HTTP Server API menyertakan struktur HTTP_REQUEST_AUTH_INFO yang disematkan dengan struktur HTTP_REQUEST . Anggota AuthStatus menunjukkan HttpAuthStatusNotAuthenticated

     

  2. Aplikasi memeriksa anggota AuthStatus dari struktur HTTP_REQUEST_AUTH_INFO untuk menentukan apakah permintaan telah diautentikasi. Jika permintaan belum diautentikasi, aplikasi dapat melayani permintaan sebagai anonim atau mengirim tantangan autentikasi 401 awal.

  3. Jika aplikasi melayani permintaan sebagai anonim, aplikasi menangani permintaan dan mengirim respons akhir ke aplikasi klien, sama seperti jika autentikasi tidak terlibat.

  4. Jika aplikasi memerlukan autentikasi, aplikasi mengirimkan tantangan 401 awal dengan satu atau beberapa header WWW-Authenticate yang menunjukkan skema yang tersedia kepada klien. Aplikasi harus menggunakan struktur HTTP_MULTIPLE_KNOWN_HEADERS untuk membangun kumpulan header yang diperlukan ketika lebih dari satu header autentikasi dikirim dalam respons.

    Catatan

    Klien mengirim ulang permintaan dengan header otorisasi untuk skema yang dipilih dari kumpulan skema yang tersedia yang ditunjukkan oleh aplikasi server dalam respons 401 awal.

    HTTP Server API memeriksa header otorisasi permintaan otorisasi untuk menentukan apakah skema diaktifkan. Jika ya, MAKA HTTP Server API melakukan autentikasi dan menangani semua pertukaran permintaan sementara/respons 401, hingga jabat tangan autentikasi diselesaikan.

    Ketika HTTP Server API menyelesaikan upaya autentikasi, API mengirimkan permintaan ke aplikasi dengan hasil upaya autentikasi dalam struktur HTTP_REQUEST_AUTH_INFO yang dikembalikan dengan permintaan. Jika upaya autentikasi gagal karena salah satu alasan berikut, HTTP Server API tidak meneruskan permintaan ke aplikasi:

    • Jika jabat tangan autentikasi gagal karena kesalahan API Server HTTP internal seperti kegagalan alokasi memori, HTTP Server API menghasilkan respons 503 (layanan tidak tersedia) dan mengirim kembali ke klien.
    • Jika header otorisasi yang salah bentuk seperti header tanpa nama skema, atau pengodean Base64 yang salah bentuk dari kredensial klien yang ditemui, API SERVER HTTP menghasilkan respons 400 (permintaan buruk) dan mengirim kembali ke klien.

     

  5. Aplikasi server memeriksa anggota AuthStatus dari struktur HTTP_REQUEST_AUTH_INFO untuk menentukan apakah autentikasi berhasil. Ketika autentikasi gagal, API Server HTTP menyertakan kesalahan yang dikembalikan dari AcceptSecurityContext di anggota SecStatus dari struktur HTTP_REQUEST_AUTH_INFO . Jika upaya autentikasi gagal karena kredensial yang buruk, aplikasi dapat menghasilkan tantangan 401 lain dengan header WWW-Authenticate yang diinginkan, atau dapat memutuskan untuk melayani permintaan sebagai anonim.

  6. Jika autentikasi berhasil, aplikasi menggunakan token yang disediakan dalam struktur HTTP_REQUEST_AUTH_INFO untuk meniru klien dan mengakses sumber daya. Handel token akses yang dikembalikan ke aplikasi valid selama ID permintaan valid, yang biasanya sampai aplikasi menyelesaikan respons terhadap permintaan. Namun, token dapat kedaluwarsa selama periode ini dan aplikasi mungkin perlu mengirim tantangan 401 lain ke klien.

  7. Aplikasi mengirimkan respons 200 OK akhir, dan harus menutup handel ke token akses.

    Catatan

    HTTP Server API menambahkan data autentikasi bersama ke respons 200 OK akhir, jika dibuat selama jabat tangan autentikasi.

     

Sesi NTLM NULL

Perhatikan bahwa sesi NTLM NULL yang ditunjukkan dalam konteks keamanan akhir, tidak diperlakukan sebagai diautentikasi. Dalam hal ini, permintaan dikirim ke aplikasi dengan kesalahan HttpAuthStatusFailure dalam struktur HTTP_REQUEST_AUTH_INFO dan aplikasi dapat mengirim tantangan 401 lainnya.

Autentikasi Preemptive

Menurut protokol HTTP, setelah klien menetapkan autentikasi untuk sumber daya, klien dapat terlebih dahulu mengirim header otorisasi yang sesuai dengan permintaan berturut-turut berikutnya untuk sumber daya tanpa menunggu tantangan 401 dari server. Jika skema yang ditunjukkan di header Otorisasi masih diaktifkan oleh aplikasi dan didukung oleh HTTP Server API, Server HTTP mencoba autentikasi tanpa mengirim permintaan ke aplikasi. Ketika jenis permintaan terautentikasi ini diterima oleh aplikasi, ia dapat memilih untuk membuang permintaan dan meregenerasi tantangan 401 awal atau melayani permintaan sebagai diautentikasi.

Autentikasi Timah

Data autentikasi bersama dihasilkan ketika skema negosiasi digunakan selama jabat tangan dan diselesaikan ke Kerberos, dan klien telah meminta autentikasi bersama. Data autentikasi bersama secara otomatis dimasukkan oleh HTTP Server API dalam respons 200 OK akhir yang dikirim oleh aplikasi server. Secara default HTTP Server API tidak meneruskan data Autentikasi timbunan ke aplikasi server, karena secara otomatis menangani pengirimannya. Namun, jika aplikasi server mengaktifkan bendera ReceiveMutualAuth dalam struktur HTTP_SERVER_AUTHENTICATION_INFO dalam konfigurasi, data autentikasi timbal balik diteruskan ke aplikasi dalam struktur HTTP_REQUEST_AUTH_INFO yang disematkan dengan HTTP_REQUEST yang diautentikasi. Dalam hal ini aplikasi harus mengirim data autentikasi bersama dengan respons 200 OK akhir. Dalam kasus di mana beberapa situs dilayani oleh satu komputer, semua situs di komputer menggunakan kredensial untuk Akun Komputer Lokal di domain untuk autentikasi bersama.

 

 

  • Last updated on