В настоящее время мы изучаем аутентификацию на основе утверждений и тестируем пользовательскую STS с использованием WIF.

Мы обсуждали, как хранить претензии в базе данных. Во многих простых примерах утверждения хранятся как простые атрибуты в одной таблице (например, UserProfile), имеющей FK для пользователя. Затем генерируются утверждения, и тип утверждения представляет собой URL-адрес и имя столбца (например, http://.../ претензии/электронная почта), и значение, конечно же, является значением из базы данных.

Но мне нужны более сложные примеры. Можете ли вы поделиться некоторыми из ваших способов хранения требований в базе данных? Я думал о чем-то вроде таблицы, содержащей все типы утверждений, и таблицы, содержащей значения для каждого пользователя (с FK для пользователя). Но нам действительно нужно немного вдохновения здесь. Так что все, чем вы можете поделиться, будет высоко оценено. Но опять же, это очень "плоская" структура...

Обновить

Я попытался сделать простую модель: http://imageshack.us/photo/ мои изображения/690/suggestionn.png/

Извините, пока не могу размещать изображения.

Я думаю, что это хорошо для простых утверждений. Но что, если у меня есть то, что я называю «вложенными утверждениями». Допустим, тип претензии описывает наличие у пользователя претензии, описывающей его права на ресурс «Персонал» типа претензии «Документы». Это можно описать с помощью этой модели, но что, если мы захотим подробнее описать это утверждение. Допустим, использование имеет уровень доступа 5 к ресурсу "Персонал". Я не понимаю, как это возможно. Любые идеи?

database authentication wif claims
0
Kirk 24 Ноя 2011 в 00:23
Претензии имеют плоскую структуру. Они не могут быть вложенными. Таким образом, утверждение будет .../Персонал/1 или .../Персонал/5 (т.е. два разных утверждения). В конечном счете, это просто строка, которую вы анализируете на стороне RP.
 – 
rbrayb
24 Ноя 2011 в 22:19
Или вы можете создать сложный тип и сериализовать его, как описано здесь: msdn.microsoft. com/en-us/library/ms734687.aspx. Что вы думаете о таком подходе?
 – 
Kirk
24 Ноя 2011 в 23:13
Это WCF, построенный на сериализации. Я не знаю о функциях STS, которые позволяют вам передавать претензии таким образом. Вы можете создавать сложные объекты на стороне RP аля syfuhs. net/post/2011/11/12/Strongly-Typed-Claims.aspx
 – 
rbrayb
24 Ноя 2011 в 23:45
Идея состоит в том, чтобы сериализовать его на стороне STS и передать в заявке как ресурс, не так ли? Затем десериализуйте его на стороне RP.
 – 
Kirk
25 Ноя 2011 в 00:16
Согласен, но утверждения передаются в токене SAML, и я не думаю, что у него есть методы для сериализации сложных объектов. См. social.msdn. microsoft.com/Forums/en-US/Geneva/thread/…
 – 
rbrayb
25 Ноя 2011 в 00:35

1 ответ

Две вещи, которые вы можете рассмотреть:

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

(Примечание: вы можете определить, какой RP с помощью параметра wtrealm).

Кроме того, типы утверждений могут быть «один ко многим». Если есть тип .../claims/groups и пользователь принадлежит к нескольким группам, будет несколько экземпляров этого типа утверждения.

Вы видели, как это реализует Identity Server? Он использует базу данных SQL.

0
MotoWilliams 9 Фев 2014 в 19:53
Спасибо за ваши комментарии. Все они отмечены. Я просмотрел Identity Server, но, насколько я вижу, он использует встроенного поставщика членства ASP.NET и добавляет такие утверждения: )); (ProviderUserRepository.cs). Также очень плоская структура.
 – 
Kirk
24 Ноя 2011 в 01:17
Я обновил свой пример с фигурой. Что ты об этом думаешь?
 – 
Kirk
24 Ноя 2011 в 17:08
Посмотрел. Вы привязываете определенных пользователей к определенным RP? Как правило, любой пользователь может получить доступ к RP. То, что вы можете делать в RP, зависит от ваших требований. Я бы убрал таблицу, привязывающую пользователей к RP, если она не нужна. Поэтому после аутентификации найдите утверждения, которые использует RP, а затем заполните утверждения на основе значений пользователя для этих утверждений. Стандарт заключается в том, чтобы не передавать пустые утверждения. Если значение утверждения пусто, не создавайте утверждение.
 – 
rbrayb
24 Ноя 2011 в 23:59
Дело в том, что не у всех пользователей есть доступ ко всем RP. У нас есть некоторые внутренние и внешние пользователи, и внешним пользователям не разрешен доступ к некоторым приложениям. Вы все еще думаете, что это неправильно? У вас нет конкретного примера того, как вы храните претензии в базе данных, которым вы готовы поделиться. Ты?
 – 
Kirk
25 Ноя 2011 в 01:01
Отправьте мне электронное письмо — имя пользователя на gmail.com.
 – 
rbrayb
25 Ноя 2011 в 02:11

Похожие вопросы

17 Как я могу перечислить таблицы в файле базы данных SQLite, который был открыт с помощью ATTACH?
1 Как запросить дополнительные претензии от Passive STS с WIF?
2 WIF STS, разные «типы» пользователей, приложения и претензии
1 Проверка подлинности на основе утверждений - SharePoint и в целом
7 Проблемы с токенами защиты от подделки
1 Можно ли моделировать сложные претензии (иерархические / вложенные и т. Д.)?
1 Как бороться с просроченными претензиями в WIF?
💵 Получи $100 на хостинг на 60 дней.
Регистрируйся!

Новые вопросы

2 Подключение к базе данных с помощью MySQL в Java
1 Symfony 6 добавляет префикс к таблицам базы данных без изменения имен сущностей
2 Чтение из FireBase
1 Как оптимизировать этот запрос в SqlAlchemy, чтобы получить последние данные?
3 Объединить десять файлов CSV без дублирования первого столбца
1 Как добавить несколько условий where в базу данных firebase Realtime
1 Количество таблиц, представлений и триггеров в SAP Business One версии 9.3? Как я мог получить эти таблицы и диаграмму отношений представлений?
1 Неверный объект в Oracle PL/SQL в недавно созданном объекте при создании пакета
1 Как мне заполнить начальные данные модели, которая имеет отношения (один ко многим) сама с собой в рельсах?
1 SQLite: проектирование круговых структур ER
Все вопросы по теме database >

database

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

Подробнее про database...