It may seem that this is a very "holivarny" question, but I still ask it.

I started writing my system back when I was in the ASP.NET Membership mode. Well, of course, I was far from having enough flexibility and I decided to write my own authorization system, not relying on any principles of authorization / authentication systems developed at that time. What about the system now resembles:

  • A separate context (you never know what happens in life);
  • CodeFirst - implementation;
  • Storing session token in cookies and comparing it with a token in a separate table in the database.
  • Authorization filters of the type ( [IdentityFilter("admin", "user", "manager")] ) and type ( [IdentityFilter(RolesEnum.Manager)] ). To choose;)
  • Repository
  • Authorization information is obtained in the filter and then walks into HttpContext`e.
  • Well, many other little things.

So, how would it work quickly, but something tells me that it can be even faster.

Actually I wanted to find out what advantages Identity can carry for me and whether it is advisable to use it in “real production”, or is it an interface for beginners and for those who do not want to be soared.

After all, in my code for me there are no restrictions, but in Identity there are still restrictions, at least the same naming of tables and fields by default.

PS I ask you a very detailed , and all the more reasoned answer. Thank you in advance!

  • one
    Table names can be changed using fluent api. - Bald
  • @Bald well with that well, got it. How to deal with the initial structure of tables, links and fields. Is it possible to refuse claims? - gromanev

2 answers 2

Membership forgotten like a bad dream, switched to Identity :

  • Need simple authorization without too much fuss? - you are welcome. Added a subsystem and forgot.
  • Need to use claims? - you are welcome. Not necessary? - you can add at any time, and until then store all the main table. And Claims will be waiting in the wings.
  • Need to add authorization through social networks? - you are welcome.
  • Do not like the naming of the fields or the table itself? - you can rename everything.
  • Need to add a new field? - you are welcome. Automatic migration, nothing needs to be deleted or backed up.
  • Need two-factor authentication with confirmation by SMS or email? - Everything is there, just add the necessary services.

  • Additional requirements for logins and passwords? - instruments of torture to choose from:

     AllowOnlyAlphanumericUserNames, RequireUniqueEmail // ------------------- RequiredLength = 6, RequireNonLetterOrDigit = false, RequireDigit = false, RequireLowercase = false, RequireUppercase = false

etc. etc.

It’s easier to load a ready-made template in the studio and pick it up for a couple of evenings to see if Identity is right for your needs. To download a working example with comments in the console, write "Install-Package Microsoft.AspNet.Identity.Samples -Pre"

Update

  • If you need a simple, flexible, functional and ready-made solution - Asp.net Identity will do. All in a box.
  • If you need to implement complex scenarios: deep security policies, simultaneous authentication using Active Directory, certificates, tokens, online forms (as on all sites), I advise you to pay attention to Windows Identity Foundation . We'll have some sweat.
  • one
    I did not use ASP.Net Identity , but the topic of authorization in general interests me. For example, now I am doing an authorization mechanism based on Claims . Please explain the phrase "if not Claims , then you can store everything in the main table." If it is approximately simplified, what structure does the table mean? Roles-actions-permissions? - Andrey K.
  • I will put "ANSWER", but it is interesting to listen to more opinions! - gromanev
  • The structure of the table can be any. On HabrĂ© there is a good article "ASP.NET 5 Identity 3 and a new authentication / authorization toolkit", perhaps some of the technical issues will disappear - Ice2burn
  • 2
    @AndreyK., Under storage in the main table, I meant the principle of laziness, I do not recommend this approach: if you do not want to mess around and deal with the Claims setting, then you can add flags to the user profile that are responsible for accessing specific parts of the site. Just by adding one line to the user's identity, we get a way to influence the behavior of the system by checking for the presence of a flag. Again, do not do this. - Ice2burn
  • 2
    @gromanev in Identity is all already there, that's just being done a little differently: privileges are set not just for roles, but for entire groups or users. So it will be possible to deny access to content to selective users, for example, with age less than 18 years and from 23.00 to 6.00 without the need to add new roles. - Ice2burn

Holivar uttermost -)

Add to the answer from a friend @ Ice2burn - authorization on the stamps is possible and quite simple to write. I wrote this and have been using production for a year and a half for a year and a half with great success. The prototype can be picked here .

Identity is actually made up of several packages:

  • Microsoft.AspNet.Identity.Core - mainly interfaces and basic implementations of classes that are not related to data storage
  • Microsoft.AspNet.Identity.EntityFramework - implementation of classes that relate to data storage. Here, everything is sharpened by EF, but all implementations can be replaced with custom storage. I have seen packages that allow you to store information about users using NHibernate or in RavenDb or Azure Tables. So the repository can be replaced without problems.
  • Microsoft.AspNet.Identity.Owin - an adapter for using OWIN and creating cookies via OWIN. In principle, it is also possible to replace it, but I cannot think of why it should be changed.

Claims is a very convenient thing. All stamps that are added to the user's record are included in authentication cookies and can be obtained from there without any problems. They can not be used, but spend half an hour understanding how they work and it will be impossible to refuse -). When a liver is created to enter the site, all user roles are actually written into cookies as stamps. The system then removes from the cookie all the stamps with the name Role . That is, you want, you do not want and the stamps are used by default. You can even say that the role is essentially a separate class of stamps.

Another very handy thing about Identity is the SecurityStamp — the GUID on the user's record. If this field changes in the database, then all user cookies are reset and you need to log in again. So you can easily prevent two people who log in from different computers under one account - useful when the business model involves payment by the number of accounts.