it-swarm-id.com

Bagaimana cara mengatur sistem masuk tunggal untuk banyak domain?

Saya telah membuat sistem masuk tunggal untuk dua situs kami yang hidup di domain yang sama: a.domain.com dan b.domain.com

Saya melakukannya melalui cookie, tetapi mereka tergantung pada domain. Dan - seperti yang tertulis di Great Book - sekarang kebutuhan untuk sistem masuk tunggal pada domain yang berbeda telah menaikkan kepalanya yang jelek :) Saya 99% yakin saya bisa melupakan tentang menggunakan OpenID (mereka tidak suka layanan eksternal di sini, saya bahkan tidak bisa membuat mereka menerima reCaptcha )

Saya ingin dapat mengidentifikasi seseorang di situs web yang berbeda (a.domain.com, b.anotherdomain.com, dll). Apa cara yang disarankan untuk menyiapkan/mengelola sistem masuk tunggal pada banyak domain? Adakah masalah keamanan khusus yang harus saya ketahui sebelum membuat proposal?

21
samy

Cara single sign-on telah diterapkan untuk Stack Exchange Network sangat menarik. Itu memanfaatkan HTML 5 Local Storage . Bergantung pada dukungan browser yang Anda butuhkan, Anda mungkin dapat menggunakan metode yang serupa.

Anda dapat memeriksa posting blog stackoverflow Global Network Auto Login untuk lebih jelasnya.

16
Mark Davidson

Anda tidak harus menggunakan layanan eksternal untuk OpenId. Anda dapat meng-host server OpenId secara internal dan menggunakannya untuk SSO Anda. Ini akan memungkinkan Anda untuk meningkatkan kode sumber terbuka dan semua pekerjaan yang telah dilakukan untuk membuat OpenId aman.

PS: OpenId dapat digunakan untuk memiliki identitas unik yang digunakan oleh banyak situs tetapi Anda masih harus login secara "manual" pada setiap domain.

5
Olivier Lalonde

Dua protokol yang baik untuk ini adalah OAuth (http://en.wikipedia.org/wiki/OAuth) dan SAML. Anda dapat menjalankan situs "penyedia identitas" Anda sendiri, menggunakan OpenID atau otentikasi lainnya) pendekatan.

5
nealmcb

Mungkin ADFSv2 (Pengunduhan gratis untuk Windows 2008R2) akan membantu Anda dengan kuki domain umum. Berikut adalah kutipan dari web.config yang terletak di C:\inetpub\adfs\ls yang harus Anda konfigurasi untuk mencapai efek yang diinginkan.

  <!--
    Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers 
    (also called Identity Providers), as described in Section 4.3.1 of Profiles for the OASIS Security 
    Assertion Markup Language (SAML) V2.0. It is recommended that you enable common domain cookies by 
    including the <commonDomainCookie> element in the web.config file.

      1.The writer attribute of the <commonDomainCookie> element specifies the address of the writer 
      service that a Claims Provider uses to set the common domain cookie once it has authenticated a user.
      This address should be a valid URL.
      2.The reader attribute of the the <commonDomainCookie> element specifies the address of the reader
      service that a claims-aware service (also called a Service Provider) uses to get the list of Claims
      Providers that it should present to the user. This address should be a valid URL.

      The following configuration enables the use of common domain cookies and specifies writer and reader 
      services as described previously. 

      A common Domain Cookie is named "_saml_idp" in 4.3.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
      Space delimited URI encoded

      RULES:
      Must be secure
      Must have path = /
      Must be leading period as in .domain.com 
      Can be session or persistant
      All providers should be configured similarly
      TODO-->
    <commonDomainCookie writer="" reader="" />
2

Banyak jawaban bagus di sini.
Ini adalah beberapa solusi bagus:

  • OpenId
  • OAuth
  • SAML
  • ADFS
  • Penyimpanan lokal

Meskipun saya tidak berpikir semua ini benar-benar sepele untuk diterapkan, tanpa belajar sedikit lebih banyak tentang mereka.

Lebih baik lagi adalah menerapkan produk web-SSO yang tepat - meskipun tampaknya dari pertanyaan Anda bahwa itu bukan pilihan (meskipun saya akan mendorong Anda untuk mempertimbangkan kembali, dan mencoba meyakinkan atasan Anda).

Salah satu solusi yang cukup sederhana yang pernah saya lihat, dan pada kenyataannya beberapa produk web-SSO menggunakan trik ini juga (perhatikan bahwa saya tidak selalu merekomendasikan pendekatan ini dalam semua situasi, lihat di bawah):
Memiliki domain "otentikasi" ketiga yang mengeluarkan "cookie identitas" (setelah mengautentikasi pengguna). Situs web di domain lain dapat mengirimkan permintaan sederhana POST ke domain otentikasi, yang tentu saja akan mencakup cookie pengguna untuk domain itu . Respons yang dikembalikan pada dasarnya akan memberi tahu domain asli, apakah pengguna diautentikasi, dan jika perlu apa identitasnya.
Jika pengguna belum diautentikasi - ia akan diarahkan ke halaman di domain otentikasi untuk mengirimkan kata sandi, dll.

Meskipun ini cukup mudah untuk diatur, perhatikan bahwa ada beberapa tantangan untuk membuatnya benar-benar aman.
Misalnya, seperti yang didefinisikan, ada situs web dapat mengambil identitas Anda. Selain itu, situs web yang mengandalkan dapat "diakali" dengan memodifikasi respons yang dikembalikan.
Tentu saja, cara paling mudah untuk menyelesaikan masalah ini adalah - Anda dapat menebaknya - SAML/OpenId/etc.

1
AviD

Saya baru saja mendaftar, tetapi ternyata mengejutkan Anda belum menemukan jawaban di tempat lain. Seperti yang sudah Anda ketahui, Anda tidak dapat mengirimkan token otentikasi pengganti menggunakan cookie.

Anda belum memberikan perincian tentang bagaimana otentikasi untuk situs Anda saat ini diterapkan atau alat yang Anda miliki untuk memprogram situs tersebut. Tapi saya akan berasumsi bahwa mekanisme otentikasi ditulis dalam bahasa yang berjalan di server web dan menggunakan cookie untuk melacak sesi.

Dalam hal ini, Anda sudah mendapatkan kode pada setiap url yang memerlukan otentikasi untuk memeriksa apakah sesi telah diautentikasi, dan kemudian mengambil tindakan yang sesuai - baik menindaklanjuti permintaan atau mengarahkan ke halaman login. Yang perlu Anda lakukan adalah menangani skenario di mana tidak ada sesi terotentikasi dan ada variabel terenkripsi yang diteruskan dalam URL (mis. Sebagai GET). Anda mendekripsi nilainya, periksa validnya dan buat sesi pada titik ini. Kemudian pada halaman login Anda, setelah login berhasil, Anda mengarahkan ulang, menambahkan pasangan kunci/nilai yang sesuai ke URL.

Itu gambaran singkat - ada beberapa penyesuaian yang perlu Anda pikirkan (mis. Anda ingin data sesi yang sama dibagikan di semua situs, apakah Anda ingin mengubah sesi untuk sesi yang berbeda untuk memastikan bahwa itu tidak kedaluwarsa di sisi server) dan Anda juga perlu memikirkan bagaimana Anda mencegah serangan replay (mis. termasuk a TTL dalam payload terenkripsi, termasuk tantangan yang dibuat secara acak, tetapi berhati-hatilah dalam menggunakan alamat IP klien).

Karena Anda hanya mengenkripsi/mendekripsi sisi server, enkripsi simetris memadai.

0
symcbean