SSO dengan CAS atau OAuth?


184

Saya ingin tahu apakah saya harus menggunakan protokol CAS atau OAuth + beberapa penyedia otentikasi untuk sistem masuk tunggal.

Skenario Contoh:

  1. Pengguna mencoba mengakses sumber daya yang dilindungi, tetapi tidak diautentikasi.
  2. Aplikasi mengalihkan pengguna ke server SSO.
  3. Jika tidak dikonfirmasi, pengguna mendapat token dari server SSO.
  4. SSO mengalihkan ke aplikasi asli.
  5. Aplikasi asli memeriksa token terhadap server SSO.
  6. Jika tokennya ok, akses akan diizinkan dan aplikasi mengetahui id pengguna.
  7. Pengguna melakukan log-out dan keluar dari semua aplikasi yang terhubung secara bersamaan (single sign-out).

Sejauh yang saya mengerti itulah yang diciptakan CAS. Klien CAS harus mengimplementasikan protokol CAS untuk menggunakan layanan otentikasi. Sekarang saya ingin menggunakan CAS atau OAuth di situs klien (konsumen). Apakah OAuth pengganti untuk bagian CAS itu? Haruskah OAuth sebagai standar de-facto baru lebih disukai? Apakah ada pengganti yang mudah digunakan (bukan Sun OpenSSO!) Untuk bagian otentikasi CAS yang mendukung berbagai metode seperti nama pengguna / kata sandi, OpenID, sertifikat TLS ...?

Konteks:

  • Aplikasi yang berbeda harus bergantung pada otentikasi server SSO dan harus menggunakan sesuatu seperti sesi.
  • Aplikasi dapat berupa aplikasi web GUI atau layanan (REST).
  • Server SSO harus memberikan ID pengguna, yang diperlukan untuk mendapatkan informasi lebih lanjut tentang peran seperti pengguna, email dan sebagainya dari toko informasi pengguna pusat.
  • Keluar tunggal harus dimungkinkan.
  • Sebagian besar klien ditulis dalam Java atau PHP.

Saya baru saja menemukan WRAP , yang bisa menjadi penerus OAuth. Ini adalah protokol baru yang ditentukan oleh Microsoft, Google dan Yahoo.

Tambahan

Saya telah belajar bahwa OAuth tidak dirancang untuk otentikasi bahkan dapat digunakan untuk mengimplementasikan SSO, tetapi hanya bersama dengan layanan SSO seperti OpenID.

Menurut saya OpenID adalah "CAS baru". CAS memiliki beberapa fitur yang terlewatkan oleh OpenID (seperti single sign-out), tetapi seharusnya tidak sulit untuk menambahkan bagian yang hilang dalam skenario tertentu. Saya pikir OpenID memiliki penerimaan luas dan lebih baik untuk mengintegrasikan OpenID ke dalam aplikasi atau server aplikasi. Saya tahu bahwa CAS juga mendukung OpenID, tetapi saya pikir CAS tidak dapat digunakan dengan OpenID.


6
Keluar tunggal adalah anti-fitur. Semua studi pengguna yang saya ketahui telah membahasnya, mengindikasikan bahwa studi ini berkisar dari yang agak membingungkan hingga yang baru bagi pengguna pemula dan yang berkuasa. Saya pribadi harus menggunakan sistem yang menggunakan keluar tunggal setiap hari, dan saya merasa sangat menjengkelkan. Hampir tidak pernah perilaku yang saya inginkan.
Bob Aman

16
Jangan setuju bahwa single sign-out adalah antifeature. Itu semua tergantung pada aplikasi yang dimaksud. Untuk aplikasi web yang entah bagaimana berhubungan satu sama lain, yaitu google mail dan google calendar, masuk akal jika Anda keluar secara eksplisit dari satu, Anda keluar dari yang lain. Dalam kasus dengan aplikasi di mana tidak ada "hubungan" yang jelas, saya setuju dengan Bob.
ashwood

6
Perhatikan bahwa pertanyaan ini awalnya ditanyakan sebelum OAuth 2.0 diperkenalkan, sehingga informasi yang terkait dengan OAuth mungkin tidak lagi benar.
Andrew

Jawaban:


238

OpenID bukan 'penerus' atau 'pengganti' untuk CAS, mereka berbeda, dalam niat dan dalam implementasi.

CAS memusatkan otentikasi. Gunakan jika Anda ingin semua aplikasi (mungkin internal) Anda meminta pengguna untuk masuk ke satu server (semua aplikasi dikonfigurasi untuk mengarah ke satu server CAS).

OpenID mendesentralisasi otentikasi. Gunakan jika Anda ingin aplikasi Anda menerima pengguna masuk ke layanan otentikasi apa pun yang mereka inginkan (pengguna memberikan alamat server OpenID - pada kenyataannya, 'nama pengguna' adalah URL server).

Tidak satu pun dari otorisasi pegangan di atas (tanpa ekstensi dan / atau kustomisasi).

OAuth menangani otorisasi, tetapi ini bukan pengganti untuk tabel 'USER_ROLES' tradisional (akses pengguna). Ini menangani otorisasi untuk pihak ketiga.

Misalnya, Anda ingin aplikasi Anda terintegrasi dengan Twitter: pengguna dapat mengizinkannya untuk tweet secara otomatis ketika mereka memperbarui data mereka atau memposting konten baru. Anda ingin mengakses beberapa layanan pihak ketiga atau sumber daya atas nama pengguna, tanpa mendapatkan kata sandinya (yang jelas tidak aman bagi pengguna). Aplikasi meminta akses Twitter, pengguna mengotorisasi (melalui Twitter), dan kemudian aplikasi mungkin memiliki akses.

Jadi, OAuth bukan tentang Single Sign-On (atau pengganti protokol CAS). Ini bukan tentang Anda mengendalikan apa yang dapat diakses pengguna. Ini adalah tentang membiarkan pengguna untuk mengontrol bagaimana sumber daya mereka dapat diakses oleh pihak ketiga. Dua use case yang sangat berbeda.

Untuk konteks yang Anda gambarkan, CAS mungkin merupakan pilihan yang tepat.

[diperbarui]

Yang mengatakan, Anda dapat menerapkan SSO dengan OAuth, jika Anda menganggap identitas pengguna sebagai sumber daya aman. Inilah yang pada dasarnya adalah 'Mendaftar dengan GitHub' dan suka. Mungkin bukan maksud asli protokol, tetapi itu bisa dilakukan. Jika Anda mengontrol server OAuth, dan membatasi aplikasi hanya untuk mengautentikasi dengannya, itu SSO.

Namun, tidak ada cara standar untuk memaksa logout (CAS memiliki fitur ini).


11
Meskipun OAuth terutama tentang otorisasi, OAuth dapat digunakan seolah-olah itu adalah server otentikasi pusat. Seperti cara akun Google OAuth digunakan oleh banyak situs (termasuk SO) untuk otentikasi, tanpa benar-benar menggunakan layanan apa pun dari penyedia OAuth.
Amir Ali Akbari

1
Selain itu, seperti yang dikatakan dalam Bertl, balasan CAS sekarang menyediakan OAuth baik sebagai klien atau server.
Anthony O.

3
Apakah jawaban ini masih relevan sekarang karena OAuth 2.0 ada? Bagaimana pendapat Anda berubah dengan OAuth 2.0?
Andrew

6
OAuth 2.0 masih merupakan protokol otorisasi dan bukan protokol otentikasi tetapi seseorang dapat membangun di atas OAuth 2.0 untuk membuat protokol otentikasi, yang telah dilakukan oleh Facebook / LinkedIn dll.; satu-satunya ekstensi standar OAuth 2.0 yang menyediakan otentikasi adalah OpenID Connect, yang merupakan penerus yang ditunjuk dari OpenID
Hans Z.

48

Saya cenderung berpikir seperti ini:

Gunakan CAS jika Anda mengontrol / memiliki sistem otentikasi pengguna dan perlu mendukung serangkaian server dan aplikasi yang heterogen yang membutuhkan otentikasi terpusat.

Gunakan OAuth jika Anda ingin mendukung otentikasi pengguna dari sistem yang tidak Anda miliki / dukung (yaitu Google, Facebook, dll).


6
OpenID adalah protokol otentikasi, OAuth adalah protokol otorisasi.
zenw0lf

13

OpenID adalah protokol otentikasi, OAuth dan OAuth WRAP adalah protokol otorisasi. Mereka dapat dikombinasikan dengan ekstensi OpenID hybrid .

Saya lebih suka melihat orang membangun di atas standar yang memiliki banyak momentum (lebih banyak dukungan yang tersedia, lebih mudah untuk melibatkan pihak ketiga), bahkan jika mereka tidak cocok untuk aplikasi yang ada. Dalam hal ini, OAuth memiliki momentum, bukan CAS. Anda harus dapat melakukan semua atau setidaknya hampir semua yang perlu Anda lakukan dengan OAuth. Pada beberapa titik di masa mendatang, OAuth WRAP harus menyederhanakan hal-hal lebih lanjut (itu membuat beberapa trade-off berharga dengan menggunakan token pembawa dan mendorong enkripsi ke lapisan protokol), tetapi masih dalam masa pertumbuhan, dan sementara itu, OAuth mungkin akan melakukan pekerjaan dengan baik.

Pada akhirnya, jika Anda memilih untuk menggunakan OpenID dan OAuth, ada lebih banyak perpustakaan untuk lebih banyak bahasa yang tersedia untuk Anda dan siapa pun yang perlu diintegrasikan dengan sistem. Anda juga memiliki lebih banyak bola mata melihat protokol, memastikan mereka benar-benar seaman seharusnya.


8

Bagi saya, perbedaan nyata antara SSO dan OAuth adalah hibah, bukan otentikasi karena server yang mengimplementasikan OAuth jelas memiliki otentikasi (Anda harus masuk ke google, openID atau facebook agar OAuth bisa terjadi dengan aplikasi klien)

Di SSO, pengguna listrik / sysadmin memberikan akses pengguna akhir ke aplikasi sebelumnya di "aplikasi SSO" Di OAuth, pengguna akhir memberikan akses aplikasi ke "datanya" di "app OAuth"

Saya tidak melihat mengapa protokol OAuth tidak dapat digunakan sebagai bagian dari server SSO. Keluarkan saja layar hibah dari arus dan biarkan server OAuth mencari hibah dari db pendukung.


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.