Создайте пользовательский провайдер авторизации для WIF, который позволяет аутентификацию по уникальным элементам - PullRequest
0 голосов
/ 25 августа 2011

Мы внедряем федеративное управление идентификацией, и у нас есть сценарий, в котором пользователям необходимо проходить аутентификацию по уникально идентифицированным элементам. Например, Боб мог иметь доступ для чтения к записям 12345, 34444, 23443 и 23443, в то время как Джейн мог иметь доступ для чтения / записи к записям 12345, 34444 и 23443 и доступ для чтения к записи 56445.

У меня два вопроса:

  1. Допустим, у кого-то есть доступ к сотне или тысяче отдельных и уникальных записей. С безопасностью на основе утверждений я понимаю, что входящий токен безопасности будет содержать все эти утверждения. Будет ли проблема с размером токена?

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

Любой совет или направление высоко ценится.

1 Ответ

1 голос
/ 31 августа 2011

На # 1: да, потенциально вы можете получить очень большой токен, если вы моделируете права как заявки (например, заявку на каждую запись, к которой у пользователя есть доступ).Если у вас 100 000 записей, вы можете получить 100 000 заявок.

«Гранулярность» утверждений является одной из тем «зависит».Как правило, рекомендуется сохранять «грубые» утверждения (например, группы, роли, организации и т. Д.), А затем связывать их с мелкозернистыми разрешениями в приложении (которые все еще могут быть реализованы декларативно).

Кроме того,Я бы предложил вам задать вопрос: «Кто является авторитетом в информации, которая будет передана в токене?»Если знание о том, что «пользователь x имеет право на чтение записи 23455 и 2456» зависит от конкретного приложения, оно относится к приложению, а не к STS.

...