Java projelerinizde hangi güvenlik çerçevesini kullanıyorsunuz?
Spring Security ve Apache Shiro'yu kullandım ve ikisi de olgunlaşmamış görünüyorlar.
Bahar Güvenliği kusurları:
- izinler için yerel destek yok;
- Java kodunda açıkça kullanılma yeteneği (bazen gerekli);
- klasik (non AJAX) web uygulamalarına çok fazla odaklandı.
Apache Shiro kusurları:
- son sürümdeki hatalar (Bahar entegrasyonu ile ilgili problem gibi);
- OpenID ve bazı yaygın olarak kullanılan teknolojiler için destek yok;
- performans sorunları bildirildi.
Her ikisi için de belge eksikliği var.
Belki de gerçek projelerin çoğu kendi güvenlik çerçevelerini geliştirir?
Apache Shiro'ya gelince:
Yaptığın şeyleri neden listelediğinden emin değilim.
- Her Dünyadaki projenin, sorgulamadan hatalar var. Ancak buradaki büyük anahtar, Shiro'nun ekibinin yanıt vermesi ve ASAP'ı düzeltmesidir. Bu, bir çerçeveyi değerlendirecek bir şey değildir, aksi takdirde, yazdığınız her şey dahil olmak üzere her çerçeveyi ortadan kaldırırsınız.
- OpenID desteği kısa bir süre Shiro 1.2'de yayınlanacak - belki bir ay sonra mı?
- Hangi performans sorunları? Kimse yok hiç Özellikle Shiro'daki önbellek desteği geniş ve birinci sınıf olduğu için, dev listelere performans sorunları bildirdi. Açıklamalar veya referanslar olmadan, bu FUD olarak karşımıza çıkıyor.
- Belgeleme şu an gerçekten iyi - son zamanlarda gördüğüm Açık Kaynaktaki en iyilerden bazıları (2 hafta önce yeniden işlendi). Sizin için kısa sürede nereye düştüğüne dair belirli örnekleriniz var mı?
Yardım etmek isterdim, ancak endişeleriniz referanslar veya somut örnekler tarafından desteklenmeyen genellemeler. Belki de projenizin şu ana kadar başaramadığınız belirli şeyleri temsil edebilir misiniz?
Apache Shiro, Java ve JVM dilleri için güvenlik çerçevesini anlamak için en esnek ve en kolay olmaya devam ediyor - daha iyi bulacağınızdan şüpheliyim.
Ama her şeyden önce, ve tüm samimiyetle bunu kastediyorum, lütfen yapamaz bir yere koymayı planladığınız sürece kendi güvenlik çerçevenizi yazınız. gülünç içine zaman miktarı. Gördüğüm neredeyse her firma bunu yapmaya çalışıyor. Bu Gerçekten mi 'doğru' almak zor (ve güvenli). Güven bana - 8 yıldan sonra yazdıktan sonra, kesinlikle eminim :)
Her neyse, Shiro kullanıcı listesine katılmaktan çekinmeyin ve topluluğun mutlu olabileceğini ve sahip olabileceğiniz sorunları çözmek için istekli olduğunu göreceksiniz. Soru sorduğumuz insanlarla ilgileneceğimizi ve yardım için elimizden geleni yapacağımızı göreceksiniz.
HTH!
Şu anki projelerim SpringSecurity kullanıyor ve SpringSecurity'de kusur olduğunu iddia ettiğiniz her üç şeyi de içeriyor:
-
Projeler, basit ROL'lerin ötesine geçen ve çeşitli etki alanı nesnelerini, ekstra istek parametrelerini ve benzerlerini içeren ince taneli erişim kuralları uygular. Bunlar, MVC denetleyicilerimde çağrılan özel "erişim ilkesi nesneleri" kullanılarak uygulanır. Ancak, erişim kontrol hataları, ilgili istisna atılarak SpringSecurity'e geri verilir. (Bunlar standart SpringSecurity yöntemi düzeyinde engelleyiciler olarak uygulanabilirdi, ancak kontroller genellikle etki alanı nesnelerini incelemeyi içerir.)
-
Projeler hem web hem de AJAX erişimini destekliyor ve iki durum için erişim hatalarıyla farklı şekilde ilgileniyor. Bu, istek URL'sine bağlı olarak farklı kimlik doğrulama davranışları arasında seçim yapmak için SpringSecurity için bazı özel Kimlik Doğrulama giriş noktası bileşenleri yazılarak yapılır.
Başka bir deyişle, yapılabilir ...
Bunu söyledikten sonra, size birkaç noktada katılıyorum:
-
Bu kadar şeyi telemek kolay değil. Kullanırken barikatlara koşmaya devam ettim
<http> eleman ve ilişkili konfigüratör. Gibi ... X bileşeninin farklı bir sürümünü kullanmak istiyorum. Ama bunun için Y, Z, P ve Q ile değiştirmek zorundasınız.
-
Dokümantasyon gerçekten seyrek ve sıradan bir şey yapmaya çalışıyorsanız yardımcı değil.
Andrey, sanırım bu cevap sana yardımcı olmak için çok geç geldi; Daha sonra bu konuya inenler için tasarlanmıştır ve umarım yardımcı olur.
Şirketim yakın zamanda açık kaynak olarak piyasaya çıktı, OACC, gelişmiş bir Java Uygulama Güvenlik Çerçevesi. OACC, nesne düzeyinde güvenlik parçacığı gerektiren sistemler için tasarlanmıştır.
OACC, sağlayan yüksek performanslı bir API sağlar izin temelli yetkilendirme hizmetleri. Özetle, OACC uygulamanızın soruyu cevaplayarak güvenliği sağlamasına izin verir: "A" öğesi, "B" varlığında "p" işlemini gerçekleştirebilir mi?
OACC’daki temel soyutlamalardan biri kaynak. bir kaynak Uygulama etki alanındaki güvenli olması gereken nesne için OACC'de yer tutucu görevi görür. Hem aktörler (örneğin kullanıcılar, süreçler) ve güvenli hale getirilen nesneler (örneğin belgeler, sunucular), OACC'de kaynak olarak temsil edilir. Aktörler olan veya güvenli olan uygulama alanı nesneleri, kaynak kimliğini yalnızca ilgili kaynağa depolar.
Kaynak soyutlaması, diğer önemli güvenlik çerçevelerinden farklı olarak, kaynakların izinlerini yöneten zengin bir API sağlamak için OACC'ye izin verir. OACC, RDBMS tablolarındaki güvenlik ilişkilerini sürdürür (DB2, Oracle, MS-SQLServer ve PostgreSQL şu anda desteklenmektedir).
Daha fazla bilgi için proje web sitesine bakınız: http://oaccframework.org
Projelerimizden birinde katmanlı bir güvenlik kullanıyoruz. Katmanlar şunlardır:
- Protokol olarak HTTPS (Apache-AJCConnectors-TomcatServlets)
- İstemci ve sunucu arasında yalnızca ikili nesneler aktarıldı
- Geçilen nesnelerdeki tek tek öğeler (her iki şekilde) şifrelenir
- Şifreleme anahtarı dinamiktir, ilk anlaşma sırasında ayarlanır, 1 oturum için geçerlidir
Kavramsal olarak güvenlik şifreleme anahtarı, şifreleme algoritması ve üzerine uygulandığı verileri içerir. İletişim sırasında 3'ten daha fazlasının aynı anda geçmediğinden emin oluruz. Umarım yardımcı olur. Saygılarımızla - M.S.