Может кто-нибудь объяснить, что означает механизм претензий в новом ASP.NET Identity Core?
Как я могу видеть, есть AspNetUserLoginsтаблица, которая содержит UserId, LoginProviderи ProviderKey.
Но я до сих пор не могу понять или найти какую-либо информацию о том, когда данные добавляются в AspNetUserClaimsтаблицу и в каких ситуациях эта таблица используется?
Ответы:
Что означает механизм заявок в новом ASP.NET Identity Core?
Существует два общих подхода к авторизации, основанных на роли и утверждении.
Ролевая безопасность
Пользователь получает одну или несколько ролей, через которые он получает права доступа. Кроме того, назначая пользователя на роль, пользователь сразу получает все права доступа, определенные для этой роли.
Безопасность на основе требований
Идентификация на основе утверждений - это набор утверждений. Заявка - это утверждение, которое сущность (пользователь или другое приложение) делает о себе, это просто утверждение. Например, список заявок может содержать имя пользователя, адрес электронной почты пользователя, возраст пользователя, авторизацию пользователя для действия. В безопасности на основе ролей пользователь представляет учетные данные непосредственно приложению. В модели на основе утверждений пользователь представляет заявки, а не учетные данные приложению. Чтобы претензия имела практическую ценность, она должна исходить от сущности, которой доверяет приложение.
Ниже приведены шаги, иллюстрирующие последовательность действий в модели безопасности на основе утверждений.
Но я до сих пор не могу понять и найти какую-либо информацию, когда данные добавляются в AspNetUserClaims и в каких ситуациях эта таблица используется?
Когда вы находитесь в ситуации, когда безопасность на основе ролей не используется, и вы решили использовать защиту на основе утверждений, вам потребуется использовать таблицу AspNetUserClaims. Чтобы узнать, как использовать утверждения в ASP.NET Identity, см. Ссылку ниже для получения дополнительной информации.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
Обновить
В какое время мне нужно использовать безопасность на основе ролей, а на основе утверждений? Не могли бы вы написать несколько примеров?
Не очень ясно, в какой ситуации вы бы использовали или не использовали бы безопасность на основе ролей или утверждений, а не случай, когда вы использовали бы А, а не Б.
Но управление доступом на основе утверждений позволяет лучше отделить правила авторизации от основной бизнес-логики. При изменении правил авторизации основная бизнес-логика остается неизменной. В некоторых ситуациях вы можете предпочесть использование подхода, основанного на утверждениях.
Иногда претензии не нужны. Это важный отказ от ответственности. Компании с множеством внутренних приложений могут использовать встроенную проверку подлинности 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 и назначьте ее любому пользователю, к которому вы хотите получить доступ, чтобы добавить объект.