ASP.NET Kimliğindeki Roller ve Talepler için En İyi Uygulamalar

Ben kullanımına tamamen yeni duyuyorum claimsiçinde ASP.NETIdentityve kullanımında en iyi uygulamaları hakkında bir fikir edinmek istiyorum Roles and/or Claims.

Tüm bu okumalardan sonra hala şu gibi sorularım var ...

S: Artık Rolleri kullanmıyor muyuz?
S: Öyleyse, Roller neden hala sunuluyor?
S: Yalnızca Hak Talepleri mi kullanmalıyız?
S: Rolleri ve Talepleri birlikte kullanmalı mıyız?

İlk düşüncem onları birlikte kullanmamız gerektiğiydi. Destekledikleri Claimsalt kategoriler olarak görüyorum Roles.

ÖRNEK İÇİN:
Rol: Muhasebe
İddiaları : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

S: Karşılıklı olarak birbirini dışlaması mı amaçlanıyor?
S: Yoksa YALNIZCA Hak Talepleri'ne gidip iddia ettiğiniz "tam yeterlilik" sağlamak mı daha iyidir?
S: Peki buradaki en iyi uygulamalar nelerdir?

ÖRNEK: Rolleri ve Talepleri Birlikte Kullanmak
Elbette bunun için kendi Öznitelik mantığınızı yazmanız gerekir ...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

ÖRNEK: İddialarınızı Tam Olarak Nitelendirme

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

Rol, aynı güvenlik ayrıcalıklarını paylaşan kullanıcıları bir araya getiren sembolik bir kategoridir. Rol tabanlı yetkilendirme, önce kullanıcının tanımlanmasını, ardından kullanıcının atandığı rollerin belirlenmesini ve son olarak bu rollerin bir kaynağa erişmeye yetkili rollerle karşılaştırılmasını gerektirir.

Aksine, bir iddia grup temelli değil, kimlik temelli.

dan Microsoft belgelerinde :

Bir kimlik oluşturulduğunda, güvenilen bir taraf tarafından yayınlanan bir veya daha fazla talep atanabilir. Talep, konunun ne yapabileceğini değil, konunun ne olduğunu temsil eden bir ad-değer çiftidir.

Bir güvenlik kontrolü daha sonra bir veya daha fazla talebin değerine bağlı olarak bir kaynağa erişim hakkını belirleyebilir.

Sen edebilirsiniz konserde hem kullanabilir ya da bir bazı durumlarda türünü ve diğer durumlarda diğer kullanın. Çoğunlukla diğer sistemlerle birlikte çalışmaya ve yönetim stratejinize bağlıdır. Örneğin, bir yöneticinin bir role atanmış bir kullanıcı listesini yönetmesi, belirli bir Talebe atanan kişiyi yönetmekten daha kolay olabilir. Talepler, bir istemciye bir talep atayabileceğiniz ve daha sonra müşterinin her talep için Kullanıcı Adı ve Parolayı iletmek yerine yetkilendirme talebini sunabileceği RESTful bir senaryoda çok yararlı olabilir.

@ Claies'in mükemmel bir şekilde açıkladığı gibi, iddialar daha açıklayıcı olabilir ve derin bir rol olabilir. Onları rol kimlikleriniz olarak düşünüyorum. Bir spor salonu kimliğim var, bu yüzden üyeler rolüne aitim. Ben de kickboks derslerindeyim, bu yüzden onlar için bir kickboks id talebim var. Başvurumun üyelik haklarıma uyması için yeni bir rol beyanına ihtiyacı olacak. Bunun yerine, çok sayıda yeni üyelik türü yerine ait olduğum her grup sınıfı için ID'lerim var. Bu yüzden iddialar benim için daha uygun.

Barry Dorrans'ın rollere karşı iddiaları kullanmanın avantajından bahseden harika bir açıklama videosu var. Ayrıca, rollerin geriye dönük uyumluluk için hala .NET'te olduğunu belirtiyor. Video; hak talepleri, roller, politikalar, yetkilendirme ve kimlik doğrulamanın çalışma şekli hakkında oldukça bilgilendirici.

Burada bulabilirsiniz: Barr Dorrans ile ASP.NET Core Yetkilendirmesi

On yıllar boyunca çeşitli kimlik doğrulama ve yetkilendirme tekniklerini kullandım, mevcut MVC uygulamam aşağıdaki metodolojiyi kullanıyor.

Hak talepleri tüm yetkilendirmeler için kullanılır. Kullanıcılara bir rol atanır (birden fazla rol mümkündür ancak buna ihtiyacım yok) - daha fazlası aşağıda.

Yaygın uygulamada olduğu gibi, ClaimsAuthorize öznitelik sınıfı kullanılır. Çoğu denetleyici eylemi CRUD olduğundan, kod ilk veritabanı oluşturmada tüm denetleyici eylemlerini yineleyen ve Oku / Düzenle / Oluştur / Sil'in her denetleyici eylem özniteliği için talep türleri oluşturan bir rutinim var. Örneğin,

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

MVC Görünümünde kullanım için, temel denetleyici sınıfı çanta öğelerini görüntüler

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

Web sitesi menüleri ve denetleyici olmayan diğer eylemler için başka iddialarım var. Örneğin, bir kullanıcının belirli bir parasal alanı görüntüleyip görüntüleyemeyeceği.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

Peki, Roller nereye uyuyor?

Bir Rolü bir (varsayılan) talepler kümesine bağlayan bir tablom var. Kullanıcı yetkilendirmesini ayarlarken, varsayılan, kullanıcıya rollerinin hak taleplerini vermektir. Her kullanıcının varsayılandan daha fazla veya daha az hak talebi olabilir. Düzenlemeyi basitleştirmek için, talepler listesi denetleyici ve eylemler (arka arkaya) tarafından gösterilir, ardından diğer talepler listelenir. Düğmeler, talepleri seçmek için gereken "tıklamayı" en aza indirmek için bir dizi eylemi seçmek için biraz Javascript ile kullanılır. Kaydedildiğinde, kullanıcıların talepleri silinir ve seçilen tüm talepler eklenir. Web uygulaması talepleri yalnızca bir kez yükler, bu nedenle herhangi bir değişiklik bu statik verilerde bir yeniden yükleme yapılmasını gerektirmelidir.

Bu nedenle yöneticiler, her bir rolde hangi taleplerin olduğunu ve bir kullanıcının bir role ve bu varsayılan taleplere atadıktan sonra hangi iddialara sahip olduğunu seçebilirler. Sistemin yalnızca az sayıda kullanıcısı vardır, bu nedenle bu verileri yönetmek kolaydır

Roller ve Talepler arasındaki farkı anlamak için rollerin sınırlandırılmasıyla yüzleşmek ve iddiaların bu sorunların üzerine nasıl geldiğini hissetmek için, rolün bu sorunları çözemediği iddiaların gücünü tanımanız için size 2 senaryo vereceğim:

1- Sitenizde iki modül var (sayfalar, servis .. vb) ilk modül ön çocuk (18 yaş altı), diğeri yetişkin için (18 yaş üstü) kullanıcı kimliğinizin doğum günü talebi var

bu talep üzerine politika oluşturmanız gerekir, böylece her modül için yetkilendirme bu değere verilecektir ve eğer kullanıcının yaşı 18 yaşın üzerindeyse, bu yaştan önce değil yetişkin modülüne gidebilir.

Rol, sahip olabileceğiniz veya sahip olamayacağınız Boole veri türüdür, rolün malty değerleri yoktur

2- Sitenizde rol kullanıcısı var ve kodu değiştirmeden bazı bakımlar yapmak için kullanıcıların erişimini engelleyemezsiniz

iddialarda, gerçek kullanıcı sayfayı görüntüleyemezse rol kullanıcısı için özellik yetkisi veren UnderConstrain politikası oluşturabilirsiniz.