Які дані слід зберігати як "Претензія"?

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

Мені цікаво, як хороша практика, які загальні дані, які слід зберігати як претензії?

Претензія - це просто факт про користувача, який потенційно може бути використаний для ідентифікації чи надання дозволу комусь у вашій системі. Цих двох обмежень повинно бути достатньо, щоб обмежити те, що ви заявляєте як вимогу.

Деякі ідеї для претензій включають:

• ідентифікатор користувача
• ім'я користувача
• електронна пошта користувача
• ролі
• членство в групі

Метадані користувача повинні бути обмежені тим, що потрібно для персоналізації програми для користувача та для асоціації користувача з його даними. Ідентифікатора користувача достатньо, щоб пов’язати користувача з даними або надати аудиторський слід. Не будь жадібним.

Ролі та членство в групі - це заявки на авторизацію. Наприклад, якщо у вашій програмі є групи, то список груп, до якого належить користувач, дозволяє швидко перевірити, чи можуть вони отримати доступ до приватної групи чи ні. Ролі є трохи більш дрібними і говорять про те, які привілеї має користувач. Зазвичай це конкретні програми, тому додайте лише те, що потрібно для виконання.

Є багато систем, особливо системи STS / федерації, які роблять це так:

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

Дані "профілю" користувача в додатку можуть не переходити до / з джерела аутентифікації, який ви використовуєте, і ви не можете використовувати одні і ті ж кінцеві точки постійно або всі користувачі.

Якщо ви були знайомі зі старою автентифікацією Forms, вона є аналогом моделі ім’я користувача та ролей, і багато вбудованих матеріалів все ще виглядає таким чином, якщо ви правильно використовуєте System.Security.Claims.ClaimTypes імені та ролі.

Ні стара, ні нова модель не дали вам багато чого з коробки для отримання позову чи спадкування ролей, але це не особливо складно втілити та реалізувати, дозволяє вам зменшити обсяг претензій або ролей, які потрібно тримати в грі від запиту вимагати.

Якщо у вашій програмі потрібно відслідковувати день народження, але не потрібно використовувати її в механізмі захисту, то насправді немає жодної користі від збереження цього в колекції вимог. Помістіть його в окремий набір даних профілю чи щось.

Якщо у вашій заяві потрібно отримати день народження як претензію в іншій системі, то ви дивитесь на щось більше, як налаштувати federatedAuthentication або дозволити збереження додаткової претензії.