Чи можете мені хтось пояснити, що означає механізм претензії в новому ядрі ASP.NET Identity?
Як я можу бачити, є AspNetUserLoginsтаблиця, яка містить UserId, LoginProviderі ProviderKey.
Але я все ще не можу зрозуміти або знайти будь-яку інформацію про те, коли дані додаються до AspNetUserClaimsтаблиці та для яких ситуацій використовується ця таблиця?
Відповіді:
що означає механізм претензії в новому ядрі Identity ASP.NET?
Є два загальні підходи до авторизації, які базуються на ролі та претензії.
Рольова безпека
Користувач отримує одну або декілька ролей, через які користувач отримує права доступу. Також, призначаючи користувача до ролі, користувач негайно отримує всі права доступу, визначені для цієї ролі.
Захист на основі претензій
Ідентичність на основі претензій - це сукупність претензій. Претензія - це твердження, яке суб'єкт господарювання (користувач чи інша програма) робить про себе, це лише претензія. Наприклад, список претензій може містити ім’я користувача, електронну пошту користувача, вік користувача, дозвіл користувача на дію. У рольовій безпеці користувач подає облікові дані безпосередньо додатку. У моделі на основі претензій користувач подає заявки, а не повноваження. Для того, щоб претензія мала практичну цінність, вона повинна виходити від суб'єкта господарювання, якому заявляється довіра.
Нижче описано послідовність того, що відбувається в моделі безпеки на основі претензій:
Але я все ще не можу зрозуміти і знайти будь-яку інформацію, коли дані додаються до AspNetUserClaims та для яких ситуацій використовується ця таблиця?
Якщо ви потрапляєте в ситуацію, коли захист на основі ролей не використовується, і ви вирішили використовувати захист на основі претензій, вам потрібно буде використовувати таблицю AspNetUserClaims. Про те, як використовувати претензії в особі ASP.NET, див. Посилання нижче для отримання додаткової інформації.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
Оновлення
Який час я повинен використовувати захист на основі ролей і коли на основі претензій? Скажіть, будь ласка, кілька прикладів?
Не дуже чітка ситуація, коли ви б хотіли або не використовували б захист, заснований на ролях або на вимогах, як не у випадку, коли ви використовували б A, а не B.
Але контроль доступу на основі претензій дозволяє краще відокремити правила авторизації від основної логіки бізнесу. Коли правила авторизації змінюються, основна логіка бізнесу залишається незадіяною. Будуть ситуації, коли, можливо, ви бажаєте використовувати підхід, заснований на претензії.
Іноді претензії не потрібні. Це важлива відмова від відповідальності. Компанії, що мають безліч внутрішніх додатків, можуть використовувати інтегровану автентифікацію Windows для досягнення багатьох переваг, наданих претензіями. Active Directory чудово справляється зі збереженням ідентифікацій користувачів, і оскільки Kerberos є частиною Windows, ваші програми не повинні включати багато логіки аутентифікації. Поки кожен створений додаток може використовувати інтегровану автентифікацію Windows, можливо, ви вже досягли своєї утопії. Однак є багато причин, чому вам може знадобитися щось інше, ніж автентифікація Windows. Можливо, у вас є веб-програми, які використовуються людьми, які не мають облікових записів у вашому домені Windows. Іншою причиною може бути те, що ваша компанія об'єдналася з іншою компанією, і ви ' у вас виникають проблеми з автентифікацією в двох лісах Windows, які не мають (і можуть ніколи) довірчих відносин. Можливо, ви хочете поділитися ідентифікаціями з іншою компанією, яка має програми, які не є .NET Framework, або вам потрібно поділитися ідентичностями між програмами, що працюють на різних платформах (наприклад, Macintosh). Це лише кілька ситуацій, коли особистість на основі претензій може бути правильним вибором для вас.
Для отримання додаткової інформації відвідайте сторінку http://msdn.microsoft.com/en-us/library/ff359101.aspx
The user presents the credentials to the issuing authority that the RP application trusts.Що ви можете використовувати як цей орган / емітент? Деякі приклади були б непогані. Я червону статтю на сайті msdn (посилання, яке ви надали), але в них наведено лише один приклад: ADFS, чи є інші варіанти? Неможливо знайти цю інформацію ніде. :(
Просто додати більше того, що @Lin сказав вище. Я спеціально замислююся над питанням:
Який час я повинен використовувати захист на основі ролей і коли на основі претензій? Скажіть, будь ласка, кілька прикладів?
Розглянемо випадок, коли у вас є система годинника, де у вас є технік і менеджер. Наприкінці кожного тижня технік повинен організувати звіти з інформацією про годинник, де відображаються години роботи ремісників, відпрацьованих за цей тиждень, які консолідуються та використовуються заробітною платою. Такі системи часто доводиться змінювати або виправляти до подання остаточних звітів, оскільки ви не хочете переплачувати або недоплачувати своїх працівників. Ви можете скористатися Role-Basedпідходом для менеджера та техніка, створивши Manager Roleта Technician Role. Але Manager Roleце той, з можливістю доступу та редагування інформації про годинник ремісників. З іншого боку, ви можете матиTechnician Roleбез цих можливостей отримати доступ до цієї інформації. Але ось цікава частина; Менеджер може подати претензію та дозволити технічному працівнику отримати доступ до систем годинника та робити звіти. Таким чином, претензія може бути подана лише для доступу без редагування або може бути зроблена з можливістю доступу та редагування.
Це більше як сказати: Ну, за замовчуванням як менеджер я можу отримати доступ до певної інформації, до якої мій технік не може отримати доступ. Але я не завжди біля офісу? що я можу зробити, щоб він ще міг виконувати роботу, навіть коли мене немає поруч? Для вирішення цього питання система може мати функцію для менеджерів створювати претензії для людей без доступу до певної конкретної інформації. Ми часто їх бачимо скрізь у наших системах ERP. Користувач, що не має доступу до деяких модулів, і коли отримують просування, вони дають дозвіл на більшість модулів ERP-системи, іноді зберігаючи ту саму роль користувача.
Це приклад, який ви можете розглянути, щоб більше зрозуміти претензії та ролі.
Існує два типи аутентифікації в ідентичності ASP.Net.
Ви можете використовувати один з них або обидва одночасно. Користуйтеся роллю, коли у вас дуже чітко визначені речі. Наприклад, ви створюєте двох викладачів і учнів. Тільки викладач може додавати предмети. Таким чином ви призначили роль вчителя тим користувачам, до яких ви хочете отримати доступ, щоб додати теми.
Позовні вимоги є більш гнучкими. Припустимо, у вас є вимога, що деякі студенти також можуть додавати предмети. У цьому випадку ви повинні створити ще одну роль, яка може бути студентом і отримати доступ, щоб додати предмет. Але якщо ви використовуєте претензії, це буде дуже просто. Просто створіть претензію на зразок addSubject і призначте її будь-якому користувачеві, до якого ви хочете отримати доступ, щоб додати об'єкт.