Какие претензии в ASP .NET Identity

Что означает механизм заявки в новом ядре идентификатора ASP.NET?

Существует два общих подхода к авторизации, основанных на роли и претензии.

Безопасность на основе ролей

Пользователь получает назначение на одну или несколько ролей, через которые пользователь получает права доступа. Кроме того, назначая пользователя роли, пользователь немедленно получает все права доступа, определенные для этой роли.

Безопасность на основе требований

Идентификация, основанная на требованиях, представляет собой набор требований. Требование представляет собой утверждение о том, что сущность (пользователь или другое приложение) делает сама, это просто требование. Например, список претензий может содержать имя пользователя, адрес электронной почты пользователей, возраст пользователей, авторизацию пользователя для действия. В режиме безопасности на основе роли пользователь вводит учетные данные непосредственно в приложение. В заявке модель, пользователь представляет претензии, а не учетные данные для приложения. Требование иметь практическое значение, оно должно исходить от объекта, которому доверяет приложение.

Ниже приведены примеры того, как это происходит в модели безопасности на основе утверждений:

• Пользователь запрашивает действие. Заявитель полагающейся стороны (RP) просит для токена.
• Пользователь представляет учетные данные выдающему органу, которому доверяет приложение RP.
• Выдающий орган выдает подписанный токен с претензиями после проверки подлинности пользователей Учетные данные.
• Пользователь представляет токен в приложение RP. Приложение проверяет токен подписи, извлечения претензий и на основании претензий либо принимает, либо отрицает запрос.

Но я все еще не могу понять и найти какую-либо информацию, когда данные добавляет к 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