Comprendo la Sicurezza basata sui ruoli . Ho letto su Basato su criteri . Ho letto ciò che altri chiama Basato su attività .
Quello che voglio sapere è se faccio policy-based, sto evitando ciò che richiede il ruolo e ciò che sembra basato sull'attività: sicurezza hardcoding, refactor a causa di qualche nuovo requisito, hardcode un po 'di più, e così via .
Vedo la differenza tra il ruolo e le attività basate. Il mio obiettivo è non avere gruppi codificati in un metodo come Admin, SuperAdmin, SuperSuperAdmin, ecc.
Penso, ma non sono sicuro se Policy Based fa quello che voglio, ma non riesco a capire come. Come sono questi tre diversi?
Se utilizzo l'esempio Under21 per i criteri che ho visto molte volte su vari blog, ho:
[Authorize(Policy = "AtLeast21")]
In che modo questo è diverso da:
[Authorize(Roles = "SuperAdministrator, ChannelAdministrator")]
public class ChannelAdministrationController: Controller
{
}
E basato sulle attività (questo Basato sul contesto ?) è diverso ma appare più "semanticamente" preciso. Hai un'attività UpdateUser e probabilmente non è probabile che tu abbia Attività SuperUpdateUser. Ma con le politiche, sembra che tu possa avere lo stesso ruolo di più ruoli. So che ci possono essere molti reclami utilizzati l'autenticazione e l'autorizzazione, ma tutto quello che posso pensare è che potrebbe esserci un nome migliore di Over21 per la mia politica e creare un ruolo di cui ha bisogno il mio reclamo. Ma da qualche parte nella parte posteriore, devo creare quelle attività e ruoli e utenti. Anche Role Based ha delle regole che posso usare in .NET Core Middleware, quindi sono confuso.
Ad esempio, potrei facilmente richiedere un criterio aggiuntivo,
[Authorize(Policy = "AtLeast21", "ExceptInTenneseeWithParent", "ExceptInChurch")]
Questa è la mia risposta (dalla pagina MS)?
services.AddAuthorization(options =>
{
options.AddPolicy("BadgeEntry", policy =>
policy.RequireAssertion(context =>
context.User.HasClaim(c =>
(c.Type == ClaimTypes.BadgeId ||
c.Type == ClaimTypes.TemporaryBadgeId) &&
c.Issuer == "https://microsoftsecurity")));
});
Torno di nuovo ai requisiti hardcoding.
La mia domanda è: in cosa differiscono?
Inoltre, la sicurezza basata sulle policy mi impedisce di dover aggiungere un nuovo ruolo o criterio ogni volta che viene fuori qualcosa di nuovo (vedi i miei esempi sopra). L'attività basata fa (sembra).
"Why do you believe that Role-Based Security is tightly coupled, while Policy-Based Security is not?"
Non sono sicuro che non lo sia. Questo è il motivo per cui ti sto chiedendo perché qualcosa non mi sta aggiungendo. Mentre questo non va bene,
[Authorize(Roles="Administrator, SuperAdministrator,
CertainBosses, SomeGuyinHR, SuperDuperAdministrator")]
Non sono convinto che la politica sia migliore,
perché devo cambiare il mio gestore con i condizionali. L'unica cosa che posso pensare è in Policy-based puoi avere un set di codice più auto-documentante che non cambia in base a un nuovo ruolo di sicurezza.
[Authorize(Policy="UpdateUser")]
e nella tua politica,
...administrator || some_user || something else
o alcune nuove norme impilate
[Authorize(Policy="UpdateUser")]
[Authorize(Policy="UpdateUserIfYouAreX")]
o nel database
...is the user in the database that has my roles
e modifica tutte le informazioni sul mio ruolo nel database.
Basato sull'attività sembra più simile all'ultima progettazione di policy:
(da lostechies)
[HandleError]
public class HomeController : Controller
{
[Authorize(Activity = "Administrators Only")]
public ActionResult AdministratorsOnly()
{
return View();
}
}