MikroProfil mikroskop altında, Bölüm 3: JWT Güvenliği
Güvenlik, yüksek oranda dağıtılmış, mikro hizmet tabanlı bir ortamda özel bir zorluk teşkil eder.RESTful hizmetleri alanında, rol tabanlı erişim kontrolü için OpenID Connect (OIDC) tabanlı JSON Web Simgeleri (JWT) standardı son yıllarda kurulmuştur. MicroProfile JWT RBAC Güvenlik (MP-JWT) özelliği de bu yığını temel alır.
Bir mikro hizmet nadiren tek başına gelir. Bu bir sır değil ama başarı tarifinin bir parçası. Mikro hizmet tabanlı bir mimarinin amacı, uygun hizmet tasarımı yoluyla bireysel hizmetlerin birbirinden mümkün olan en büyük bağımsızlığını elde etmektir. Peki ya güvenlik? Maksimum bağımsızlık ilkesi burada da geçerli mi? Ve öyleyse, bir müşterinin her hizmet ve hatta her hizmet çağrısı için kullanıcı kimlik bilgileriyle (ör. kullanıcı adı ve parola) kimlik doğrulaması yapması ve kendisini ayrı ayrı yetkilendirmesi gerekir mi?
JWT Hızlı Başlangıç Kılavuzu
Dağıtılmış hizmetler alanında, OpenID Connect’e dayalı JSON web belirteç standardı (ayrıca bkz. the yerleşik norm.
Basitçe söylemek gerekirse, bu yöntemle bir istemci, bir kimlik doğrulama sunucusuyla (Yayıncı) ve karşılığında zaman sınırlı, kişiselleştirilmiş ve genellikle imzalanmış bir belirteç (JWS ile JWT) alır. Bu bağlamda, özel, güvenlik belirtecinin sözde talepler, yani anahtar-değer çiftleri içerdiği anlamına gelir; bu arada . Kimliği doğrulanmış kullanıcı bilgileri (Ders) içermek.
Belirteç yardımıyla, müşteri artık harici hizmetlerle iletişim kurabilir (kaynak sunucusu) taşıyıcı kimlik doğrulamasını kullanarak kimlik doğrulaması yapar. Bunu yapmak için, her istekle birlikte yetkilendirme başlığındaki belirteci göndermeniz yeterlidir:
GET /resource/123 HTTP/1.1
Host: openknowledge.com
Authorization: Bearer mF_9.B5f-4.1JqM
İmza sayesinde, aranan servisler belirtecin gerçekliğini ve gerçekliğini doğrulayabilir. Belirteç, müşteri hakkında bilgi içerdiğinden, çağrılan hizmetler ayrıca rol tabanlı erişim kontrolü (RBAC) – yetkilendirme yapabilir.
Bu prosedürün faydası açıktır. Belirteçler ve içerdikleri bilgiler sayesinde bir hizmet, kullanıcı veya kimlik yönetimi hizmeti gibi üçüncü bir taraftan ek bilgi talep etmek zorunda kalmadan hem kimlik doğrulama hem de yetkilendirme yapabilir. Bu gereksiz gidiş-dönüşlerden tasarruf sağlar. Bu arada, bu, aranan servis başka bir servisi aradığında da geçerlidir (hizmet zinciri). Bu durumda, orijinal olarak çağrılan hizmet, içerdiği tüm kullanıcı bilgileri de dahil olmak üzere belirteci istek başlığına (Güvenlik bağlamı yayılımı).
Mikroprofil ve JWT
1.2 sürümünden bu yana, MP-JWT 1.0 spesifikasyonuna sahip MicroProfile, JWT tabanlı güvenliği de desteklemektedir. Spesifikasyon birkaç noktada başlar ve aşağıdaki faaliyetleri desteklemeyi amaçlar:
- belirteçleri istekten çıkarın,
- belirteçleri doğrulamak ve doğrulamak,
- Belirteç taleplerini erişilebilir hale getirin
- JavaEE güvenlik bağlamını oluşturun ve ayarlayın.
- Adam: Token Formatı (“JWT”) Başlık parametresi
- alg: şifreleme algoritması (“RS256”) için başlık parametreleri
- oğlan: Benzersiz anahtar kimliği için ipucu içeren başlık parametresi
- yemek için: belirteç veren
- alt: Jetonun nesnesi (İlke/Kullanıcı)
- ses: Beklenen hedef grup
- önceki: Geçerlilik
- bende: emisyon süresi
- jti: benzersiz tanımlayıcı
- üzerinde: Benzersiz ilke adı (java.security.Principle için)
- gruplar: Uygulama rollerine eşleme için grup adlarının listesi
{
"typ": "JWT",
"alg": "RS256",
"kid": "abc-1234567890"
}
{
"iss": "https://auth.openknowledge.com",
"aud": "kNowLedGe",
"jti": "ok-12345",
"exp": 1311281970,
"iat": 1311280970,
"sub": "13579",
"upn": "[email protected]",
"groups": ["first-group", "second-group", "admin"],
}
Simgenin, isteğin yetkilendirme başlığından otomatik olarak çıkarılması için, JAX-RS uygulamasına ilk olarak MP-JWT kimlik doğrulaması ve yetkilendirmesi için JASPI’nin (Kapsayıcılar için Java Kimlik Doğrulama SPI’si) kullanılacağının bildirilmesi gerekir. Bu açıklama ile yapılır LoginConfig paketten org.eclipse.microprofile.jwt.
…
import org.eclipse.microprofile.auth.LoginConfig;
…
// Sets the authentication method to the MP-JWT for the MicroProfile JWT.
// The optional parameter realName is only needed, if authMethod
// is set to "BASIC" or for vendor specific configurations.
@LoginConfig(authMethod = "MP-JWT", realName="...")
@ApplicationScoped
@ApplicationPath("/myapi")
public class MyJaxrsApp extends Application { }
dipnot: açıklama LoginConfig MicroProfile olası dağıtım formatları hakkında ve dolayısıyla bir servlet kabının veya bir sunucu uygulamasının varlığı hakkında hiçbir açıklama yapmadığı için tanıtıldı. web.xml Tahmin edilebilir. Bu bir web.xml mevcutsa, ek açıklamanın kullanımına alternatif olarak aynı adın girişi kullanılabilir login-config içinde web.xmldosyalar kullanılır.
Sonraki belirteç doğrulaması arka planda otomatik olarak gerçekleşir. Bunu yapmak için, MicroProfile çalıştırma zamanı kapsayıcısı yapılandırmasında yalnızca belirteç verenin ortak anahtarı saklanmalıdır. Ek olarak, bir belirtecin geçerli bir MP-JWT olarak değerlendirilmesi için en azından aşağıdaki koşulları karşılaması gerekir:
- Jetonun RS256 aracılığıyla imzalandığını gösteren JOSE (JavaScript Nesne İmzalama ve Şifreleme) başlığı
- MicroProfile çalışma zamanı kapsayıcısında yapılandırılan aynı belirteç vereni içeren iss
Çıkarıldıktan ve doğrulandıktan sonra, belirteç veya bireysel belirteç taleplerine CDI aracılığıyla mikro hizmet içinde erişilebilir. Erişim, ham türler, ClaimValue sarmalayıcılar, javax.enterprise.inject.Instance veya JSON-P türleri aracılığıyla olabilir:
@Path(/endpoint)
@DenyAll
@RequestScoped
public class SomeEndpoint {
// 1) JWT object with @RequestScoped scoping
@Inject
private JsonWebToken callerPrincipal;
// 2) JWT as raw String
@Inject
@Claim(standard = Claim.raw_token)
private String rawToken;
// 3) IAT claim as Long value
@Inject
@Claim(standard=Claims.iat)
private Long issuedAt;
// 4) ISS claim as ClaimValue of type String
@Inject
@Claim(standard=Claims.iss)
private ClaimValue<String> issuer;
// 5) JTI claim as optional ClaimValue of type String
@Inject
@Claim(standard=Claims.jti)
private ClaimValue<Optional<String>> optJti;
// 6) JTI claim as JsonString
@Inject
@Claim(standard=Claims.jti)
private JsonString jsonJti;
// 7) custom claim "roles" as JsonArray
@Inject
@Claim("roles")
private JsonArray jsonRoles;
// 8) custom claim "customObject" as JsonArray
@Inject
@Claim("customObject")
private JsonObject jsonCustomObject;
...
}
dipnot: yukarıdaki listede gösterilen sınıf Bazı Uç Nokta proxy olmayan türleri içeren @ReqiestScoped kapsamında olmalıdır (sırım Ve Uzun) belirteçten enjekte edilebilir.
Şu anda kayıtlı arayan veya ilişkili belirteç, kullanılarak etkinleştirilebilir. @lnject JsonWebToken kapsam ile @RequestScoped enjekte edilecek (1). gelen Müdür türetilmiş arayüz JsonWebToken belirtecin en önemli taleplerine (Ad, Veren, Genel, Konu, TokenID, ExperiationTime, IssuedAtTime, Gruplar) hedefli ve güvenli bir şekilde erişmek için bir dizi uygun yöntem sunar.
Alternatif olarak, krediler de doğrudan enjekte edilebilir. Bu, String(2) veya Long(3) gibi proxy olmayan bir ham tür olarak yapılırsa, çevreleyen bean kapsamdan gelmelidir. @RequestScoped yapı. Talebi ham tip olarak eklemek yerine alternatif olarak talebin değerini ve/veya isteğe bağlı sarmalayıcıları (4 ve 5) kullanabilirsiniz. JSON-P’de (6, 7 ve 8) tanımlanan türler aracılığıyla erişim de mümkündür.
Yazım hatalarından kaçınmak için, standart taleplere erişirken her zaman talep numaralandırması kullanılmalıdır. Öte yandan, özel taleplere erişmek için dizeler veya kendi numaralandırmanız kullanılabilir.
JAX-RS konteyner entegrasyonu
Artık JSON Web Simgesini istekten otomatik olarak çıkarabildiğimize ve ardından doğrulayabildiğimize göre, JAX-RS kaynakları içindeki olağan JavaEE güvenlik mekanizmalarını kullanabilmemiz elbette güzel olurdu. Ve MP-JWT spesifikasyonu da bunu sağlar.
Bir yöntem çağrısı getUserPrinciple() sınıf javax.ws.rs.core.SecurityContext bize mevcut olandan bir örnek verir JsonWebToken Dönüş. Benzer şekilde, yöntemi çağırabiliriz. isUserInRole(bir Rol) iddiada belirtilen rolün olup olmadığını kontrol edin gruplar jetonun dahil olup olmadığı. Ayrıca açıklama yardımı ile @RollesAllowed(…) Belirtilen rollere göre tek tek yöntemlere erişimi kilitleyin veya serbest bırakın.
Sonuç ve perspektif
Bir JSON web belirtecini ayıklamak, doğrulamak ve doğrulamak için gereken adımları – JavaEE güvenlik bağlamında aktarmak dahil – uygulayabilecek “şanslı” olan herkes, entegre ve standartlaştırılmış bir çözümün faydalarını takdir eder. Bu, özellikle belirteç içinde beklenen talepler için geçerlidir.
Bununla birlikte, tüm konsept, sonunda MP-JWT formatına dahil olan yeterli kimlik sağlayıcıları ve hizmet sağlayıcıları olacağı gerçeğiyle ayakta durur ve düşer. Olasılığı artırmak için, “isteğe bağlı olmayan” şikayetleri seçerken tekerleği yeniden icat etmekten kasıtlı olarak kaçındık ve bunun yerine IANA JWT atamasında standartlaştırılmış şikayetlerin beş alt kümesini seçtik. Yalnızca iki “isteğe bağlı olmayan” ifade – üzerinde (kullanıcı ilke adı) e gruplar (JavaEE güvenlik rolleriyle eşlenen Konu Belirteci Grupları) – tescillidir.
Gelecekteki sürümler için bazı ifadeler daha planlanmıştır. Bu yüzden onaylamaların yardımıyla olmalı kaynak_erişimi hizmete özel roller belirleyebilirsiniz. Halihazırda var olan iddiaya ek olarak, halen incelenmektedir. gruplar ayrıca şikayet roller mevcut Sırasında gruplar hedef kaynak rol modeline eşlenecek içerilen değerler için tasarlanmıştır; roller içerilen değerler birer birer geçirilir ve @RollerAllowed Kullanılabilir.
Şaşırtıcı olan, ortak anahtar erişimi gibi yapılandırma modunun, MP Config API kullanmak yerine ilgili çalışma zamanı kapsayıcısı üreticilerine bırakılmasıdır. Bununla birlikte, standardizasyon için zaten karşılık gelen hususlar vardır. Meraklı olabilirsin.
()
Haberin Sonu