.NET uygulaması için izinler / doğru model / kalıp


9

Esnek VE basit (böyle bir şey varsa) uygulamam gerekiyor ve aynı zamanda mümkünse yerleşik araçlar kullanmalıyım

Şimdiye kadar MembershipProvider ve RoleProviders uyguladım. Bu harika ama bir sonraki adımda nereye gideceğim?

"Priviledge" terimini eklemem gerekiyor ve uygulamanın içindeki sabit koddan daha fazla. Kullanıcılar Rollere Ayrıcalıklar eklemek ve kullanıcılara Rol atamak için rolleri yapılandırır.

Bu iyi bir model gibi mi geliyor? Rollere eklemenin yanı sıra Kullanıcı düzeyinde ayrıcalıklar eklemeyi düşünmeli miyim? Yapabilirim ama kurulum (kafa karıştırıcı) ve aşağıdaki destek ile ilgili sorunları öngörüyorum.

Bunu yapmazsam ve bazı belirli kullanıcıların daha az ayrıcalığa ihtiyacı varsa - yöneticinin başka bir rol oluşturması gerekir.

Böyle bir sistem için gümüş mermi var mı? Microsoft neden sadece Üyelik ve Rol sağlayıcılarından daha ileri gitmedi?

Başka bir fikir: Rolleri "ayrıcalık" sahibi olarak bırakın ve sabit kodlayın. Sonra tüm mevcut biçimlendirme / öznitelikleri, vb - tüm Microsoft kullanarak uygulama içindeki rolleri kodlayabilirsiniz.

Yeni varlık "Grup" ekleyin ve bunun gibi bir ilişki oluşturun

  • Kullanıcılar
  • Kullanıcı Grupları
  • Gruplar
  • RoleGroups
  • Roller

Bu şekilde Rolleri gruplara toplayabilir ve bu grupları Kullanıcılara atayabilirim. Harika görünüyor ve diğer yazılım desenleriyle eşleşiyor. Ama sonra gerçekten RoleProvider içinde bir şeyleri uygulayamıyorum:

  • AddUsersToRoles
  • RemoveUsersFromRoles

Ve bazı şeyler artık gerçekten mantıklı değil çünkü kodlanacaklar

  • DeleteRole
  • CreateRole

Yanıtlar:


5

Rol tabanlı yetkilendirme sizin için yeterince ayrıntılı değilse, Talep Bazlı Yetkilendirmeyi kullanmayı düşünün .

Bir hak talebi bir kaynağı ve etkinliği açıklar - bir ACL'deki girişe benzer, ancak daha esnektir, çünkü "kaynak" fiziksel bir nesne olmak zorunda değildir, olmasını istediğiniz herhangi bir şey olabilir ve herhangi bir bilgi içerebilir İstediğiniz.

Bu modelde bir hak talebi "ayrıcalık" olarak adlandırdığınız şeye eşdeğerdir ve hak taleplerini, "rol" olarak adlandırdığınız şeye kabaca eşdeğer olan talep kümelerine gruplandırırsınız. Bu API'lerin tümü ve daha fazlası System.IdentityModelad alanında.

Tabii ki bahsediyorsunuz MembershipProviderve RoleProvidertüm bunları ASP.NET üyelik modeline sıkıştırmaya çalışıyorsanız (bu isimlerin ima ettiği gibi), sadece unutun. Bu sağlayıcı API'larını kullanmak istiyorsanız, bunu kendi yollarıyla yapmanız gerekir ve yolları bir rol kavramından daha ayrıntılı olmaz.

Bunun yerine, ASP.NET'te, "ayrıcalık" kavramı aslında eylem veya işlem düzeyinde kodlanır ve burada hangi rollerin bu eylemi gerçekleştirmesine izin verildiğini bildirirsiniz. Bu sadece bir [AuthorizeAttribute]denetleyicileri veya denetleyici eylemleri tokat nerede ASP.NET MVC ile başa çıkmak için çok daha kolaydır ; "old-school" ASP.NET'te etkinlikleri yönetiyorsunuz, bu nedenle yetkilendirme ya geçici ya da sayfa düzeyinde (ya da her ikisinde) olma eğilimindedir.


Çok fazla bilgi, teşekkürler! App aslında sunucu WCF RESTful hizmet olarak maruz kısmı Silverlight app. Talep Tabanlı ilginç görünüyor, ancak kullanıcı ve otorizasyon kavramını fark etmedim. Az önce bulduğum ilginç makale: geekswithblogs.net/shahed/archive/2010/02/05/137795.aspx
katit

@katit: .NET'teki neredeyse tüm kimlik doğrulama / yetkilendirme IPrincipal arabirimini temel alır . Eğer beyana dayalı yetkilendirme yapıyorsanız o zaman kullanmak IClaimsPrincipal bunun için, ve dökme IPrincipaliçin IClaimsPrincipalhak talebinin kontrolleri yapmak istediğinizde. (Örneğin) Form Kimlik Doğrulaması'na uymak istiyorsanız, kendi kodunuzun çoğunu yazacaksınız, ancak açıkça (bağlantıya göre) yapılabilir.
Aaronaught

soru şu: Belki üyelik / rol sağlayıcılarına başka bir "Grup" seviyesi eklemek veya kendi sağlayıcınızı yazmak daha kolaydır? Microsoft olanları uygulamakla hemen hemen aynı iş
katit

3
@katit: Ünlü son sözler. Kendinizi icat etmek için çok iyi bir nedeniniz yoksa kendiniz icat etmeyin ("daha kolay görünüyor" iyi bir neden değildir; sadece doğrudan deneyiminiz olmadığında ve dolayısıyla gereken iş miktarı).
Aaronaught
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.