Что такое преимущество IPrincipal/IIdentity, а не пользовательский класс пользователя, который содержит необходимые вам свойства и использующий его для аутентификации/авторизации?В чем преимущество хранения пользователей в IPrincipal/IIdentity?
Очевидные преимущества заключаются в следующем: вся концепция аутентификации приложения & авторизация основана на принципалах и тождествах, выраженных как IPrincipal/IIdentity. Из-за этого встроенные механизмы чаще всего предполагают, что эти два используются. И если они используются, встроенные механизмы могут работать.
Возьмите веб-приложения, например. Пользователь HttpContext на всю жизнь запроса выражается как IPrincipal. Соглашаясь с этим соглашением, вы позволяете механизму авторизации правильно оценить, разрешен ли пользователю доступ к веб-ресурсам. Это связано с тем, что и модуль WebForms UrlAuthorization, и атрибут MVC Authorization предполагают, что принципал хранится стандартным способом.
В настольных приложениях у вас есть ThreadCurrentPrincipal, который также является IPrincipal.
Замена IPrincipal/IIdentity с собственными интерфейсами аутентификации/авторизации займет навсегда. Вам придется переписать большинство частей библиотеки базового класса, которые занимаются аутентификацией/авторизацией, а вместо встроенных интерфейсов вы будете полагаться на свою пользовательскую реализацию.
Но я не вижу никакого отношения между двумя заявлениями, которые вы представили. Вы спросили о преимуществе IPrincipal над пользовательским классом. Но IPrincipal - это просто интерфейс (!!), и ваш пользовательский класс может легко его реализовать. То же самое с IIdentity. Затем вы можете разместить свои пользовательские классы везде, где ожидается IPrincipal.
Это может быть немного сложно, например, в веб-приложениях вам придется заменить встроенные модули аутентификации, которые настроили IPrincipal. Наиболее часто используются два: FormsAuthenticaiton, который использует GenericPrincipal/FormsIdentity и SessionAuthenticationModule, который использует ClaimsPrincipal/ClaimsIdentity. Ваш пользовательский модуль может, напротив, использовать любую пользовательскую реализацию, которую вы хотите.
«В настольных приложениях у вас есть CurrentTincipal Thread» - также в серверных приложениях. – Joe
@Joe: true. Я просто хотел привести несколько примеров, а не всю историю. –
Стандартные методы аутентификации, такие как Active Directory, Windows Identity Foundation и Windows, все используют IPrincipal и IIdentity. В принципе, если вы хотите использовать какой-либо из встроенных механизмов аутентификации, вы должны использовать эти классы. Как правило, у вас будет специальная схема базы данных для хранения информации о пользователе, и вы создадите объекты IPrincipal и IIdentity из этих данных, чтобы сделать аутентификацию.
Это интерфейсы, вы не «храните пользователя» в интерфейсе. У них есть обычное преимущество интерфейсов, контракт, который не привязан к конкретной реализации. Полезно ли, чтобы ваш класс реализовал эти интерфейсы, немного сомнительно, но неясно из вопроса. –