Тёмный

Flexible Authorisation with ASP.NET Core 7.0 - Jason Taylor - NDC Oslo 2023 

NDC Conferences
Подписаться 199 тыс.
Просмотров 9 тыс.
50% 1

Опубликовано:

 

27 окт 2024

Поделиться:

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист
Посмотреть позже
Комментарии : 12   
@hemant-sathe
@hemant-sathe Год назад
Excellent talk Jason. Very crisp and to the point. This approach could be extensible for more application specific requirements. I can think of rule based access to resources such as access based on specific attributes of an object. That would require some work though, but this is a good starting point.
@shahnawazk
@shahnawazk Год назад
As always nice and precise. Thanks Jason!
@allannielsen4752
@allannielsen4752 Год назад
Excellent talk but I think a lot of people don't get that this is only one way to do it, everyone seems to be stuck on the enum implementation. The enum is just a "simplistic" way to represent a requirement, and policies can be made up of many requirements, as long as the "requirement" handler understands the algorithm you can do anything here. if you want to make it a string and make the last five characters "CRUDE" (Create, Read, Update, Delete, Execute) there is nothing stopping you from doing that, then a preceeding prefix could represent the resource you want to secure. You could go even further and make multiple "Translators" where a prefix character determines which to use (e.g. F123CR = Use the flexible translator, for resource 123 and require read and create). The Auth system is ultimately flexible because you write the Requirements, RequirementHandler and PolicyBuilder, so as long as you set context.Succeed(requirement) when needed, you can do anything. Don't forget there is a lot more to a mature system than CRUD too, MinimumAgeRequirement for example, Valid Registration Number, etc).
@mouradaissani8957
@mouradaissani8957 Год назад
Thanks Jason!
@giorgiarakhamia3380
@giorgiarakhamia3380 Год назад
Where can I find a github link
@MrUlly23
@MrUlly23 Год назад
Using this kind of policy matching must be fast, but you can define only 64 permissions (using long enum) so not really a realistic approach
@flibbertigibbet6324
@flibbertigibbet6324 Год назад
I am adopting a policy authorization layer similar to Jason's permission design and so far the application's 35 pages and UI commands have been grouped into 6 permission policies. I don't feel there is any chance I will exhaust the 64 bits available in a long enum as the system grows.
@MrUlly23
@MrUlly23 Год назад
@@flibbertigibbet6324 it really comes down on how you want to define your policies. If you don't need granular control over the actions, you can create some giant policies and you are Ok. In my case i want to split permissions between view, edit, delete for every entity, just making a blazor application to manage users, roles and their permissions i have something like 10 policies. It depends on your requirements. I don't really get then need of this talk, he is making a layer over the default layer that already manages policies only to make an abstraction. In my case i just define a role claim, create a policy with the same definition (using reflection at startup), set the claims to one/multiple role/s and use it in the authorization level int both server rest and the client. It's simpler and i can store the permissions at database level the same without a limit on the number.
@flibbertigibbet6324
@flibbertigibbet6324 Год назад
@@MrUlly23 I think the talk helps technical architects move from a traditional Role based view of authorization towards using policies without ditching the familiarity of Roles. In recent years the message from elsewhere has been over simplified to "Roles= Bad, Claims=Good and oh consider policies as well". My perspective is that authorization Policies are the central building block whereas Roles or Claims are just bits of data attached to an identity declared with an authentication service. With respect to policy granularity I can understand that given a strict RESTful view of web application design then you might want to set permissions for each HTTP verb operation on each entity. My own applications have moved a long way from REST to CQRS and I just need to authorize access to projected views plus business task operations. I find this leads to natural grouping of operations for authorization , rather than "giant policies" I benefit from much policy reuse.
@cherifdiallo5592
@cherifdiallo5592 2 месяца назад
First of all congrate to you Jason. Great work. Am I the only one that downloaded this source code from Git and Cannot build the solution I keep getting the following message: "Severity Code Description Project File Line Suppression State Details Error (active) NETSDK1141 Unable to resolve the .NET SDK version as specified in the global.json located at C:\Downloads\To Use\flexible-aspnetcore-authorization-main\global.json. FlexibleAuth.Client, FlexibleAuth.Server, FlexibleAuth.Shared C:\Program Files\dotnet\sdk\8.0.303\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.targets 128" What am I doing wrong? Can anyone help? I would love to be able to use this in project and enhance my knowledge of C# Best regards Thank you..
Далее
Implementing JWT Authentication in ASP.NET Core
23:51