Какие данные должны храниться как `Заявка`?

В ASP.Net Core я считаю Claimsавторизацию очень не конкретным методом. Мы можем добавить что угодно как ClaimTypeи ClaimValueпару; groups, firstname, фамилия, brithdate, canAccessThisURI, isEditor и т. д. Однако этот подход (хранение всего, что может быть сохранено как утверждения) создаст огромную таблицу утверждений, которая включает 50% данных моего приложения.

Как хорошая практика, мне интересно, какие общие данные должны храниться в качестве претензий?

Заявка - это просто факт о пользователе, который потенциально может использоваться для идентификации или авторизации кого-либо в вашей системе. Этих двух ограничений должно быть достаточно, чтобы ограничить то, что вы бы назвали претензией.

Некоторые идеи для претензий включают в себя:

• ID пользователя
• имя пользователя
• электронная почта пользователя
• роли
• членство в группах

Метаданные пользователя должны быть ограничены тем, что необходимо для персонализации приложения для пользователя и для связи пользователя с его данными. Идентификатора пользователя достаточно, чтобы связать пользователя с данными или предоставить контрольный журнал. Не жадничай.

Роли и членство в группах являются утверждениями. Например, если в вашем приложении есть группы, то список групп, к которым принадлежит пользователь, позволяет быстро проверить, могут ли они получить доступ к частной группе или нет. Роли немного более детализированы и говорят о том, какие привилегии имеет пользователь. Обычно они зависят от приложения, поэтому добавляйте только то, что вам нужно для обеспечения соблюдения.

Есть много систем, особенно систем STS / федерации, которые делают это следующим образом:

• одно утверждение, которое описывает пользователя однозначно
• ассортимент претензий, описывающих общие концептуальные вещи, к которым они (и другие) имеют доступ

Данные «профиля» пользователя в приложении могут не переводиться в / из источника аутентификации, который вы используете, и вы не можете использовать одни и те же конечные точки постоянно или для всех пользователей.

Если вы были знакомы со старой проверкой подлинности с помощью форм, она аналогична модели имени пользователя и ролей, и многие встроенные функции по-прежнему выглядят так, если вы используете System.Security.Claims.ClaimTypes имени и роли соответствующим образом.

Ни старая, ни новая модель не давали вам много возможностей для наследования утверждений или ролей, но это не особенно сложно реализовать, а реализация позволяет сократить объем утверждений или ролей, которые необходимо сохранить в запросе от запроса. запрашивать.

Если вашему приложению необходимо отслеживать день рождения, но не нужно использовать его в механизме безопасности, тогда действительно нет никакой пользы в сохранении его в коллекции требований. Поместите это в отдельный набор данных профиля или что-то.

Если вашему приложению необходимо получить день рождения в качестве заявки от другой системы, тогда вы рассматриваете что-то большее, например, настройку federatedAuthentication или разрешение сохранения дополнительной заявки.