Может кто-нибудь объяснить, что означает механизм требований в новом ядре идентификатора ASP.NET?
Как я вижу, существует таблица AspNetUserLogins, которая содержит UserId, LoginProvider и ProviderKey.
Но я все еще не могу понять или найти какую-либо информацию о том, когда данные добавляются в таблицу AspNetUserClaims и в каких ситуациях эта таблица используется?
Что означает механизм заявки в новом ядре идентификатора ASP.NET?
Существует два общих подхода к авторизации, основанных на роли и претензии.
Безопасность на основе ролей
Пользователь получает назначение на одну или несколько ролей, через которые пользователь получает права доступа. Кроме того, назначая пользователя роли, пользователь немедленно получает все права доступа, определенные для этой роли.
Безопасность на основе требований
Идентификация, основанная на требованиях, представляет собой набор требований. Требование представляет собой утверждение о том, что сущность (пользователь или другое приложение) делает сама, это просто требование. Например, список претензий может содержать имя пользователя, адрес электронной почты пользователей, возраст пользователей, авторизацию пользователя для действия. В режиме безопасности на основе роли пользователь вводит учетные данные непосредственно в приложение. В заявке модель, пользователь представляет претензии, а не учетные данные для приложения. Требование иметь практическое значение, оно должно исходить от объекта, которому доверяет приложение.
Ниже приведены примеры того, как это происходит в модели безопасности на основе утверждений:
Но я все еще не могу понять и найти какую-либо информацию, когда данные добавляет к AspNetUserClaims и в каких ситуациях эта таблица использует для?
Когда вы находитесь в ситуации, когда защита на основе ролей не используется, и вы решили использовать основанную на требованиях Безопасность, вам нужно будет использовать таблицу AspNetUserClaims. О том, как использовать Претензии в Identity 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
Просто чтобы добавить больше к тому, что @Lin сказал выше. Я специально задаюсь вопросом:
В какое время мне нужно использовать безопасность на основе ролей, а на основе утверждений? Не могли бы вы написать несколько примеров?
Рассмотрим случай, когда у вас есть система синхронизации, где у вас есть техник и менеджер. В конце каждой недели технический специалист должен составлять отчеты с информацией о синхронизации, показывающей часы работы ремесленников, работавших на эту неделю, которые консолидируются и используются для расчета заработной платы. Такие системы часто должны быть исправлены или исправлены перед отправкой окончательных отчетов, потому что вы не хотите переплачивать или недоплачивать своим сотрудникам. Вы можете использовать Role-Based на Role-Based подход для менеджера и технического специалиста, создав Manager Role и Technician Role. Но Manager Role - это та, которая имеет возможность доступа и редактирования информации о часах ремесленников. С другой стороны, вы можете иметь Technician Role без этих способностей для доступа к этой информации. Но вот интересная часть; Менеджер может подать заявку и предоставить техническому специалисту доступ к системам синхронизации и составить отчеты. Таким образом, выражение может быть сделано только для доступа без редактирования или может быть сделано с возможностями доступа и редактирования.
Это больше похоже на высказывание: "Ну, по умолчанию, как менеджер, я могу получить доступ к некоторой информации, к которой у моего техника нет доступа". Но я не всегда в офисе? что я могу сделать, чтобы он все еще мог выполнять работу, даже когда меня нет рядом? Чтобы решить эту проблему, система может иметь возможность для менеджеров создавать заявки для людей, не имеющих доступа к какой-либо конкретной информации. Мы часто видим это везде в наших системах ERP. Пользователь не имеет доступа к некоторым модулям, и когда они получают повышение, они дают разрешение большему количеству модулей системы ERP, иногда сохраняя одну и ту же роль пользователя.
Это пример, который вы можете рассмотреть, чтобы лучше понять требования и роли.