ASP.NET Identity VS Самописная система авторизации

#c_sharp #aspnet #aspnet_mvc #oauth2 #aspnet_identity_2

Может показаться что это очень "холиварный" вопрос, но я всё же задам его.

Начинал писать свою систему ещё тогда, когда был в моде ASP.NET Membership. Ну естественно,
гибкости мне далеко не хватало и я решил писать свою систему авторизации, не опираясь
на какие-то устоявшиеся в те времена принципы разработки авторизационных/аутентификационных
систем. Что примерно из себя напоминает система сейчас:


Отдельный контекст (мало ли что в жизни бывает);
CodeFirst - реализация;
Хранение токена сессии в кукисах и сравнение его с токеном в отдельной таблице в БД.
Авторизационные фильтры типа ([IdentityFilter("admin", "user", "manager")]) и типа
([IdentityFilter(RolesEnum.Manager)]). На выбор ;)
Репозиторий.
Авторизационная информация получается в фильтре и далее гуляет в HttpContext`e.
Ну и много других мелочей.


Так вот, как бы работает быстро, но что то подсказывает мне, что можно ещё быстрее. 

Собственно хотелось узнать, какие преимущества может нести для меня Identity и целесообразно
ли его использование в "реальном продакшне", или же это интерфейс для новичков, и для
тех, кто не хочет парится.

Ведь в моём коде для меня нет никаких ограничений, а вот в Identity ограничения всё
таки есть, хотя бы то же самое именование таблиц и полей по умолчанию.

P.S. Прошу очень развёрнутый, и тем более аргументированный ответ. Заранее спасибо!
    

Ответы

Ответ 1

Membership забыл как страшный сон, перешел на Identity:


Нужна простая авторизация без лишней возни? - пожалуйста. Добавил подсистему и забыл.
Нужно использовать Claims? - пожалуйста. Не нужно? - можно добавить в любой момент,
а до тех пор хранить все основной таблице. А Claims так и будет ждать своего часа.
Нужно добавить авторизацию через соцсети? - пожалуйста.
Не нравятся именование полей или самой таблицы? - можно все переименовать.
Нужно добавить новое поле? - пожалуйста. Автоматическая миграция, ничего не нужно
удалять или бэкапить.
Необходима двухфакторная аутентификация с подтверждением по смс или электронной почте?
- Всё есть, просто добавить необходимые службы.
Дополнительные требования к логинам и паролям? - орудия пыток на выбор:

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



и т.д. и т.п.

Проще в студии загрузить готовый шаблон и поковырять его пару вечерков, чтобы точно
убедиться подходит ли Identity для своих нужд.
Для загрузки рабочего примера с комментариями в консоли пишем «Install-Package Microsoft.AspNet.Identity.Samples
-Pre»

Update


Если нужно простое, гибкое, функциональное и готовое решение - Asp.net Identity подойдет.
Все в коробке.
Если необходимо реализовывать сложные сценарии: глубокие политики безопасности, одновременная
аутентификация по Active Directory, сертификатам, токенам, онлайн формам (как на всех
сайтах), то советую обратить внимание на Windows Identity Foundation. Придется несколько
попотеть.


Ответ 2

Холивар полнейшей -) 

Добавлю к ответу от товарища @Ice2burn - авторизация по клеймам возможна и достаточно
проста в написании. Я написал подобное и уже года полтора в продакшне использую с большим
успехом. Прототип можно поковырять здесь. 

Identity состоит на самом деле из нескольких пакетов:


Microsoft.AspNet.Identity.Core - в основном интерфейсы и базовые имплементации классов
которые не относятся к хранению данных
Microsoft.AspNet.Identity.EntityFramework - имплементации классов которые относятся
к хранению данных. Здесь все заточенно под EF, но все имплементации могут быть замененны
на кастомное хранилище. Я видел пакеты которые позволяют хранить информацю о юзерах
использую NHibernate или в RavenDb или Azure Tables. Так что хранилище может быть замененно
без проблем.
Microsoft.AspNet.Identity.Owin - адаптер для использования OWIN и создания кукисов
через OWIN. В принципе тоже можно заменить, но не могу придумать зачем это менять.


Claims - весьма удобная вещь. Все клеймы которые добавленны в запись юзера попадают
в authentication куки и их оттуда можно достать без проблем. Их можно не использовать,
но потратить полчаса на понимание как они работают и отказаться будет невозможно -).
Когда создается печенка для входа на сайт, все пользователькие роли на самом деле записываются
в куку как клеймы. Система потом достает из куки все клеймы с названием Role. То есть
хочешь-не хочешь а клеймы используются по дефолту. Можно даже сказать что роли это
по сути отдельный класс клеймов.

Еще одна очень удобная вещь в Identity это SecurityStamp - GUID на записи пользователя.
Если это поле меняется в базе, то сбрасываются все пользователькие куки и надо логиниться
по-новой. Так можно легко предотвращать двух людей которые логинятся с разных компов
под одним аккаунтом - полезно когда бизнес модель предполагает оплату по количеству
аккаунтов.