Bagikan melalui


Federasi

Federasi memungkinkan delegasi otoritas otorisasi kepada anggota lain dari interprise. Misalnya, pertimbangkan masalah bisnis berikut: Perusahaan manufaktur suku cawala otomatis Contoso Ltd ingin mengizinkan karyawan resmi pelanggannya Fabrikam Inc untuk mengakses layanan Web pesanan suku CA Contoso dengan aman. Salah satu solusi keamanan untuk skenario ini adalah agar Contoso menyiapkan mekanisme kepercayaan dengan Fabrikam untuk mendelegasikan keputusan otorisasi akses ke Fabrikam. Proses ini dapat berfungsi sebagai berikut:

  • Fabrikam, ketika menjadi mitra Contoso, menyiapkan perjanjian kepercayaan dengan Contoso. Tujuan dari langkah ini adalah untuk menyetujui jenis token keamanan dan konten yang akan mewakili otorisasi Fabrikam dan akan dapat diterima contoso. Misalnya, dapat diputuskan bahwa sertifikat X.509 tepercaya dengan nama subjek "CN=Fabrikam Inc Supplier STS" harus menandatangani token SAML agar SAML tersebut diterima oleh Contoso Web Service. Selanjutnya, dapat diputuskan bahwa klaim keamanan dalam token SAML yang dikeluarkan harus berupa 'https://schemas.contoso.com/claims/lookup' (untuk otorisasi pencarian bagian) atau 'https://schemas.contoso.com/claims/order' (untuk otorisasi pemesanan bagian).
  • Ketika karyawan Fabrikam menggunakan aplikasi pemesanan suku cakap internal, pertama-tama menghubungi layanan token keamanan (STS) di dalam Fabrikam. Karyawan tersebut diautentikasi menggunakan mekanisme keamanan Fabrikam internal (misalnya, nama pengguna/kata sandi domain Windows), otorisasinya untuk memesan bagian diverifikasi, dan dia mengeluarkan token SAML berumur pendek yang berisi klaim yang sesuai dan ditandatangani oleh sertifikat X.509 yang diputuskan di atas. Aplikasi pemesanan bagian kemudian menghubungi layanan Contoso yang menyajikan token SAML yang dikeluarkan untuk mengautentikasi dan melakukan tugas pemesanan.

Di sini, Fabrikam STS bertindak sebagai 'pihak penerbit' dan layanan suku cawala Contoso bertindak sebagai 'pihak yang mengandalkan'. Diagram memperlihatkan pihak penerbit dan pihak yang mengandalkan di federasi.

Fitur Federasi

Berikut ini adalah fitur keamanan yang didukung untuk pihak atau peran yang terlibat dalam skenario federasi:

  • Sisi klien: Untuk mendapatkan token keamanan dari STS, seseorang dapat menggunakan fungsiWsRequestSecurityToken. Atau, seseorang dapat menggunakan pustaka penyedia token keamanan sisi klien seperti CardSpace atau LiveID, lalu menggunakan output mereka untuk membuat token keamanan secara lokal menggunakan WsCreateXmlSecurityToken. Bagaimanapun, setelah klien memiliki token keamanan, kemudian dapat membuat saluran ke layanan yang menentukan WS_XML_TOKEN_MESSAGE_SECURITY_BINDING untuk menyajikan token, bersama dengan pengikatan keamanan transportasi seperti WS_SSL_TRANSPORT_SECURITY_BINDING untuk melindungi saluran.
  • Sisi server: Dalam skenario federasi dengan layanan token keamanan yang mengeluarkan token SAML, server dapat menggunakan WS_SAML_MESSAGE_SECURITY_BINDING, bersama dengan pengikatan keamanan transportasi seperti WS_SSL_TRANSPORT_SECURITY_BINDING untuk melindungi saluran.
  • Sisi STS: Perhatikan bahwa STS adalah aplikasi Layanan Web, dan dapat menentukan persyaratan keamanan bagi mereka yang meminta token keamanan darinya menggunakan deskripsi keamanan struktur pada waktu pembuatan pendengar sama seperti yang dilakukan Layanan Web aman lainnya. Kemudian dapat mengurai payload pesan permintaan masuk untuk memvalidasi permintaan token dan mengirim kembali token yang dikeluarkan sebagai payload pesan balasan. Saat ini, tidak ada fitur yang disediakan untuk membantu penguraian dan langkah-langkah penerbitan ini.

Perhatikan bahwa sisi klien dapat menangani token keamanan yang dikeluarkan secara generik sebagai token keamanan XML tanpa mengetahui jenis token, atau melakukan pemrosesan khusus jenis token. Namun, server harus memahami jenis token keamanan tertentu untuk memahami dan memprosesnya. Langkah-langkah permintaan dan respons token keamanan menggunakan konstruksi yang ditentukan dalam spesifikasi WS-Trust.

Skenario Federasi yang Lebih Kompleks

Skenario federasi dapat melibatkan beberapa STS yang membentuk rantai federasi. Pertimbangkan contoh berikut:

  • Klien mengautentikasi ke LiveID STS menggunakan nama pengguna/kata sandi LiveID, dan mendapatkan token keamanan T1.
  • Klien mengautentikasi ke STS1 menggunakan T1 dan mendapatkan token keamanan T2.
  • Klien mengautentikasi ke STS2 menggunakan T2 dan mendapatkan token keamanan T3.
  • Klien mengautentikasi ke layanan target S menggunakan T3.

Di sini, LiveID STS, STS1, STS2 dan S membentuk rantai federasi. STS dalam rantai federasi dapat melakukan berbagai peran untuk skenario aplikasi secara keseluruhan. Contoh peran fungsional STS tersebut termasuk penyedia identitas, pembuat keputusan otorisasi, anonim, dan manajer sumber daya.

Parameter Permintaan STS dan Pertukaran Metadata

Agar klien berhasil melakukan panggilan WsRequestSecurityToken, klien perlu mengetahui parameter panggilan tersebut (seperti jenis token dan jenis klaim yang diperlukan), deskripsi keamanan persyaratan saluran permintaan ke STS, dan alamat titik akhir STS. Aplikasi klien dapat menggunakan salah satu teknik berikut untuk menentukan informasi ini:

  • Kode keras informasi dalam aplikasi sebagai bagian dari keputusan waktu desain.
  • Baca informasi ini dari file konfigurasi tingkat aplikasi yang disiapkan oleh penyebar aplikasi lokal.
  • Temukan informasi ini secara dinamis saat runtime menggunakan fitur impor metadata dengan struktur WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT.

Untuk mengilustrasikan penggunaan MEX dinamis dengan federasi, pertimbangkan contoh 3 STS di atas. Klien pertama-tama akan melakukan MEX dinamis dengan S untuk mendapatkan informasi tentang T3 (yaitu, apa yang harus ditanyakan dari STS2) serta alamat MEX dinamis STS2 (yaitu, tempat menemukan STS2). Kemudian akan menggunakan informasi tersebut untuk melakukan MEX dinamis dengan STS2 untuk menemukan informasi tentang T2 dan STS1, dan sebagainya.

Dengan demikian, langkah-langkah MEX dinamis terjadi dalam urutan 4, 3, 2, 1 untuk membangun rantai federasi dan permintaan token dan langkah-langkah presentasi berlangsung dalam urutan 1, 2, 3, 4 untuk melepas rantai federasi.

Nota

Windows 7 dan Windows Server 2008 R2: WWSAPI hanya mendukung Ws-Trust dan Ws-SecureConversation seperti yang didefinisikan oleh Lightweight Web Services Security Profile (LWSSP). Untuk detail mengenai implementasi Microsoft, silakan lihat bagian Sintaks MESSAGE LWSSP.