Mikro Hizmet Kimlik Doğrulama stratejisi


138

Bir mikro hizmet mimarisi için iyi / güvenli bir kimlik doğrulama stratejisi seçmekte zorlanıyorum. Bu konuda bulduğum tek SO yazı şudur: Mikro Hizmet Mimarisinde Tek Oturum Açma

Buradaki fikrim, her hizmette (örn. Kimlik doğrulama, mesajlaşma, bildirim, profil vb.) Her kullanıcı için benzersiz bir referans (oldukça mantıklı bir şekilde onun user_id) ve idoturum açmışsa geçerli kullanıcının alınabilmesi.

Araştırmalarımdan, iki olası strateji olduğunu görüyorum:

1. Paylaşılan mimari

Paylaşılan mimari

Bu stratejide, kimlik doğrulama uygulaması diğerlerinin yanı sıra bir hizmettir. Ancak her hizmet, dönüşümü session_id=> yapabilmelidir, user_idböylece basit olmalıdır. Bu yüzden Redis'i düşündüm, bu anahtar: değeri saklardı session_id:user_id.

2. Güvenlik duvarı mimarisi

Güvenlik duvarı mimarisi

Bu stratejide, yalnızca kimlik doğrulama uygulaması tarafından işlendiği için oturum depolaması gerçekten önemli değildir. Sonra user_iddiğer hizmetlere iletilebilir. Rails + Devise (+ Redis veya mem-cached veya çerez depolama, vb.) Düşündüm ama tonlarca olasılık var. Önemli olan tek şey Service X'in kullanıcının kimliğini doğrulaması gerekmeyeceğidir.


Bu iki çözüm aşağıdakiler açısından nasıl karşılaştırılır:

  • güvenlik
  • sağlamlık
  • ölçeklenebilirlik
  • kullanım kolaylığı

Ya da belki burada bahsetmediğim başka bir çözüm önerirsiniz?

1 numaralı çözümü daha çok seviyorum ama doğru yönde gittiğimde beni güvence altına alacak çok fazla varsayılan uygulama bulamadım.

Umarım sorum kapanmaz. Başka nereden soracağımı gerçekten bilmiyorum.

Şimdiden teşekkürler


1
Neyi başarmaya çalıştığınızla ilgili daha fazla ayrıntıyı lütfen öngörebilir misiniz? İlk durumda, Redis'e veya hizmetlerin kendilerine karşı kimlik doğrulaması gerçekleşir mi? İkinci diyagramda Redis eksik, bu kasıtlı mı?
Plamen Petrov

Biraz bilgi ekledim. Lütfen hala belirsiz olduğunu bana bildirin. Teşekkürler!
Augustin Riedinger

OAuth Protokolü'nü kullanan bir mikro hizmet yaratma fikrini ve başkalarının hizmet belirteci Token'i oluşturmayı düşündünüz mü?
Tiarê Balbi

Bu çözümü merak ediyorum, ancak hala pratikte nasıl çalışacağını anlamıyorum. Bazı standart uygulamalarını nerede bulabileceğimi biliyor musunuz?
Augustin Riedinger

@AugustinRiedinger, bunu eklediğin için teşekkürler. Ayrıca monolitik web uygulamamı bebek adımlarını atıp mikro hizmetlere bölüyorum. Sizin durumunuzda, Hizmetler 1-n vatansız veya eyalet doludur. Devlet dolu olmaları durumunda, bu hizmetlerin her birinde oturumları yönetmeyi düşündünüz mü? Teşekkürler
Manchanda. P

Yanıtlar:


61

Anladığım kadarıyla, bunu çözmenin iyi bir yolu OAuth 2 protokolünü kullanmaktır ( http://oauth.net/2/ adresinde bu konuda biraz daha bilgi bulabilirsiniz )

Kullanıcı uygulamanızda oturum açtığında bir jeton alacak ve bu jetonla istekte tanımlamak için diğer hizmetlere gönderebilecekler.

OAuth 2 Modeli

Zincirli Mikro Hizmet Tasarımı Örneği Mimari Modeli

Kaynaklar:


1
Teşekkürler oldukça açık. Bu çok iyi makaleyi hemen hemen aynı çözümü çürütürken buldum
Augustin

16
Cevabınız harika, ancak API Ağ Geçidinden (bunun içinden veya bir AuthMicroService) oluşturulan jeton, amacı kimlik doğrulaması olmayan ve muhtemelen içinde oauth yönetimine sahip olmayan rastgele bir mikro hizmet tarafından nasıl ele alınabilir? onun iş kodu?
mfrachet

Örneğin, ağ geçidinde alınan jetonu tüm hizmetlere göndermek için Netflix Zuul'u kullanabilirsiniz ve kullanıcı bilgilerini bilebilirler. docs.spring.io/spring-boot/docs/current/reference/htmlsingle/…
Tiarê Balbi

OAuth2'yi hizmetler arasında kullanma ile ilgili bir başka güzel şey de, hizmet kimlik doğrulaması ile kullanıcı kimlik doğrulaması eylemlerini birbirinden ayıran uç noktalara sahip olabilmenizdir.
cmp

2
OAuth daha çok bir kullanıcının başka bir sistemde tutulan verilere sisteme erişim izni vermekle ilgilidir. Bu benim için SAML için iyi bir durum gibi görünüyor.
Rob Grant

8

Kısa cevap: Bir webapp veya mobil uygulama gibi her türlü uygulamada kullanılabilen Oauth2.0 tür belirteci tabanlı kimlik doğrulamasını kullanın. Bir web uygulaması için gereken adımların sırası,

  1. kimlik sağlayıcıya karşı kimlik doğrulaması
  2. erişim kodunu çerezde tut
  3. web uygulamasındaki sayfalara erişme
  4. hizmetleri arayın

Aşağıdaki şemada ihtiyaç duyulacak bileşenler gösterilmektedir. Web ve veri apislerini ayıran böyle bir mimari, iyi bir ölçeklenebilirlik, esneklik ve kararlılık verecektir

resim açıklamasını buraya girin


AWS Lambda "soğuk" olmaz ve başlaması zaman alır mı? Bu girişi yavaşlatır, değil mi?
tsuz

@tsuz, AWS artık lambda'da eşzamanlılığı ayırabileceğiniz eşzamanlılık özelliği tanıttı. Bununla soğuk çalıştırma problemini çözebilirsiniz. docs.aws.amazon.com/lambda/latest/dg/…
Sandeep Nair

Bu cevabı yıllar önce görmeyi çok isterdim, kimlik doğrulama ve yetkilendirme ile mikro hizmet mimarisinin diğer mikro hizmetlerin diğer hizmetlere erişim vermek için nasıl yönetilebileceğini anlamak inanılmaz derecede basit
brayancastrop

@Sandeep, sanırım Hazır eşzamanlılıktan bahsediyorsun ve rezerve edilmemişsin.
Anil Kumar

0

Bunu OpenID Connect kullanarak uygulamak için API ağ geçidi deseni kullanılmalıdır. Kullanıcının kimliği IDP tarafından doğrulanacak ve JWT belirtecini yetkilendirme sunucusundan alacaktır. Artık API ağ geçidi sistemi bu belirteci Redis veritabanında saklayabilir ve çerezi tarayıcıda ayarlayabilir. API ağ geçidi, kullanıcı isteğini doğrulamak için çerezi kullanır ve jetonu Mikro hizmetlere gönderir.

API Ağ Geçidi, Microservice mimarisindeki genel java komut dosyası istemci uygulaması, geleneksel web uygulaması, yerel mobil uygulama ve üçüncü taraf istemci uygulamaları gibi her tür istemci uygulaması için tek bir giriş noktası görevi görür.

Bununla ilgili daha fazla bilgiyi http://proficientblog.com/microservices-security/ adresinde bulabilirsiniz.


-2

kimlik doğrulama ve yetkilendirme amacıyla idenitty server 4'ü kullanabilirsiniz

Güvenlik Duvarı Mimarisini kullanmanız gerekir, bu nedenle güvenlik, sağlamlık, ölçeklenebilirlik ve kullanım kolaylığı üzerinde daha fazla kontrole sahip olursunuz

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.