Расширение поставщиков ролей ASP.NET

Question

Поскольку интерфейс RoleProvider, кажется, обрабатывает роли как не что иное, как простые строки, мне интересно, есть ли какой-нибудь нехакерный способ применить необязательное значение для роли для каждого пользователя.

Наша нынешняя система управления входом в систему реализует роли в виде пар ключ-значение, где часть значения является необязательной и обычно используется для уточнения или ограничения разрешений, предоставляемых ролью.

Например, роль «редактор» может содержать пользователя «Барри», но для «Барри» она будет иметь необязательное значение «raptors», которое система будет интерпретировать как означающее, что Барри может редактировать только статьи, поданные под категория "хищники".

В других местах я видел предложение просто создать дополнительные роли с разделителями, такие как «editor.raptors» или что-то подобное. Это на самом деле не будет идеальным, потому что это значительно увеличит количество ролей, и я могу сказать, что замена нашей текущей реализации будет очень трудно продать (что также очень далеко от идеала, но имеет преимущество в том, что пользовательский сделано для работы с нашей базой данных пользователей).

Я уже могу сказать, что упомянутый выше метод конкатенации будет включать в себя много утомительного разделения строк и частичного сопоставления.

Есть ли лучший способ?

РЕДАКТИРОВАТЬ: Моя первоначальная цель состояла в том, чтобы использовать более встроенные функции ASP.NET. Например, контролировать доступ через элементы <authorization/> в Web.config. Для этого, насколько я могу судить, требуются сами роли. Концепция аутентификации нашей нынешней системы, казалось, очень хорошо соответствовала этому ограничению.

Ответы на вопросы mnemosyn

1. Да. У нас есть центральная база данных для пользователей, приложений и их авторизаций. Это базовая система, и обойти ее невозможно.
2. В настоящее время наша система не является иерархической, и для ее обслуживания требуется довольно много усилий. Когда приложение создается, определяется набор полномочий (например, «admin», «user», «poweruser», «gatekeeper», «keymaster» и т. Д.). Затем пользователи связываются с этими авторизациями с необязательным значением для уникальной комбинации авторизации пользователя и (для конкретного приложения).
3. Можете ли вы уточнить эти «категории», о которых вы говорите?

Answer 1

Это действительно звучит как архитектурная проблема для меня.

Во-первых, вам нужно точно определить, что вам нужно. На втором этапе сопоставьте это с конкретной реализацией. Забегая вперед, я бы не стал использовать встроенные провайдеры ни для чего, кроме самых простых случаев. Кроме того, эта проблема быстро усложняется, поэтому я постараюсь сделать ее максимально простой.

Чтобы уточнить ваши потребности, попробуйте определить:

• Вам действительно нужно сопоставить концепцию роли с базой данных, как в CMS? Или же изменения в вашей системе ролей подразумевают изменение системы. В этом случае вы могли бы пойти на гораздо более простое решение и поместить enum в пользователя. Это сэкономит много обращений к базе данных, облегчит выбор соединений и т. Д.
• Чего вы пытаетесь достичь с помощью концепции много ролей, которую вы объяснили? Это действительно роли, которые вам нужны? Как насчет индивидуальных разрешений? У вас, например, есть иерархическая структура, так что каждый узел может иметь определенный набор разрешений, связанных с ним, во многом как концепция безопасности файлов Windows?
• Если это только категории, почему бы не отобразить категории для пользователей, то есть дать каждому пользователю определенную роль в каждой категории. Это потребует некоторых настроек для категории по умолчанию и т. Д.

Несколько советов: не используйте белые списки, всегда используйте черные списки. Контролировать белые списки - это боль, особенно когда много правил собираются вместе. В drupal, например, я думаю, что это один из главных недостатков (именно поэтому они перестраивают его, чтобы использовать черные списки в версии 7). Позволить пользователю делать то, что он не должен, обычно намного сложнее, чем наоборот.

Концепция доступа к файлам Windows очень сложна, поскольку в ней есть как черный, так и белый списки, которые дополнительно могут быть унаследованы, поэтому постарайтесь сделать свое решение намного проще, чем это.

Мне кажется, что штука с конкатенацией строк опасна для меня, в любом случае, я бы выбрал более чистое решение. Этот тип мета-логики вызывает головную боль.