Merancang otentikasi untuk REST API

11

Saya sedang mengerjakan API untuk layanan REST yang akan saya produksi dan konsumsi. Saya telah menghabiskan beberapa hari terakhir mencoba mencari cara untuk menangani otentikasi dengan baik, dan berpikir saya akhirnya menemukan sesuatu.

Saya datang dengan ini berdasarkan fakta-fakta berikut tentang tumpukan aplikasi:

  1. Klien & Server berada di .NET4 (Bagian klien dalam Profil Klien)
  2. Server terpapar menggunakan WCF REST
  3. Saya benar-benar tidak ingin menyimpan nama pengguna dan kata sandi di memori dalam aplikasi

Dari 3, saya ingin menggunakan bentuk otentikasi token, sehingga setelah kredensial diverifikasi oleh server, klien mendapat token kembali untuk digunakan sepanjang sisa aplikasi (ini akan memungkinkan saya untuk melakukan hal-hal lain, seperti mengatur waktu pengguna, dapat memindahkan pengguna dengan mulus antara versi web dan desktop, dll). Setelah mencari tahu cara membuat panggilan ulang dan mengutak-atik, saya telah datang dengan yang berikut:

  1. Sebelum klien mencoba untuk mengotentikasi, itu menghasilkan pasangan kunci Diffie-Hellman menggunakan ECDiffieHellmanCngkelas.
  2. Ini mengirimkan bagian publik dari pasangan kunci melalui kawat bersama dengan nama pengguna dan kata sandi (Tentu saja HTTPS).
  3. Server mengautentikasi kombinasi nama pengguna / kata sandi, jika berhasil, ia akan melakukan yang berikut:
    1. Membuat token sesi unik
    2. Menghasilkan pasangan kunci DH sendiri, dan menghitung rahasia bersama dari kunci publik yang disediakan oleh klien
    3. Membuat catatan dari token sesi, rahasia bersama, pengguna, dan waktu "aksi terakhir" (digunakan untuk jendela kedaluwarsa bergulir) dalam database-nya
    4. Mengembalikan token sesi, kunci DH publiknya, dan pesan keberhasilan otentikasi
  4. Klien mengambil kunci DH dari respons, menghitung rahasia bersama, dan menyimpan token dan rahasia dalam memori.

Sejak saat ini, kombinasi token / rahasia sesi berfungsi seperti kebanyakan REST API lainnya, dengan permintaan yang diambil sidik jari dan cap waktu, dan kemudian menghasilkan semacam HMAC. Setiap kali klien melakukan tindakan terhadap server, itu memeriksa token / pasangan rahasia, dan memungkinkan tindakan jika valid dan tidak kedaluwarsa, dan memperbarui catatan tindakan terakhir dalam sesi.

Saya tidak melihat kekurangan yang jelas, dan mungkin terlalu banyak direkayasa untuk ini, tetapi saya perlu belajar bagaimana melakukan ini di beberapa titik. HMAC mencegah serangan replay, negosiasi DH membantu mencegah serangan MITM (Saya tidak bisa memikirkan serangan yang bisa dilakukan dari atas kepala saya antara HMAC / DH).

Adakah lubang yang bisa ditusuk orang dalam hal ini?

algorithms rest authentication Matt Sieker
sumber
Saya tidak melihat bagaimana membuat kunci DH menambahkan keamanan sama sekali dibandingkan dengan hanya menggunakan HTTPS di mana-mana dan menggunakan cookie sesi lama. Ketika digunakan dengan benar, HTTPS sudah melindungi terhadap serangan man-in-the-middle dan replay.
Lie Ryan

Jawaban:

5

Daripada membuat sendiri, Anda harus mempertimbangkan membaca API OpenAM dan meminjamnya.

http://forgerock.com/openam.html

OpenAM Wiki sangat membantu

https://wikis.forgerock.org/confluence/display/openam/Home

Anda tidak perlu menggunakan komponennya. Tetapi jika Anda menggunakan API mereka, Anda akan menemukan bahwa hidup Anda akan lebih sederhana dalam jangka panjang.

S.Lott
sumber
Hmm, itu tidak terlihat buruk, satu hal yang mencegah saya menggunakannya dalam kasus ini: Kami adalah toko Net. Plus, tidak banyak tentang menggunakannya dengan sisi server WCF hal. Satu tautan non-spam yang bisa saya temukan di google tentang hal itu menunjuk pada penggunaan WIF dan WS-Federation.
Matt Sieker
1
@ Mat Sieker: "Anda tidak perlu menggunakan komponen mereka". Harap baca tentang API mereka alih-alih menciptakan milik Anda.
S.Lott
Ah, saya pikir saya mengerti maksud Anda, persyaratan panggilan balik. Itu menarik, saya mungkin akan melihat lebih dalam, jika bukan untuk proyek ini, untuk yang akan datang. Alih-alih melakukan auth sebagai satu potongan atom,
pisahkan
Kami awalnya menggulung sendiri tetapi kemudian pindah ke OpenAM beberapa tahun yang lalu di IG Group. Sangat senang dengan produk open source.
Robert Morschel
2

Saya setuju 100% dengan @ S.Lott bahwa Anda tidak ingin roll sendiri. Saya sarankan mencari alternatif lain: Layanan Kontrol Akses Windows Azure (ACS). ACS membutuhkan biaya, tetapi sangat murah (10.000 transaksi untuk $ 0,01) dan banyak infrastruktur yang ditangani. WIF dimanfaatkan pada klien.

Ini juga merupakan solusi berbasis standar / klaim - yang merupakan hal yang paling disukai. Lihat artikel ini tentang menggunakan WCF dan REST dan ACS bersama-sama .

Jika Anda memikirkan masa depan, ini juga merupakan mekanisme yang dapat tumbuh bersama Anda - karena Anda memiliki aplikasi seluler di luar firewall, mitra, dan sebagainya. Bahkan jika Anda tidak ingin menggunakannya karena itu menambah ketergantungan di luar firewall Anda, Anda mungkin ingin memeriksanya untuk gagasan. Sangat licin.

Semoga berhasil! -Tagihan

codingoutloud
sumber