Справочный пример для ClaimsAuthorizationManager в Windows Identity Foundation 4.5

Извините за длинный вопрос, пытаюсь донести до всех свои мысли!

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

У меня есть две основные цели: 1) Иметь возможность сообщать о том, какие бизнес-операции/задачи может выполнять пользователь? 2) Иметь возможность отслеживать в режиме реального времени или через исторические отчеты, что пользователь делает/сделал?

В настоящее время мы используем сочетание настраиваемой аутентификации и авторизации (используя серверную часть SQL для обоих) и службы домена AD для аутентификации и требования членства/роли в группе AD для авторизации.

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

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

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

Поэтому я ищу любые советы о том, как разработать схему авторизации корпоративного класса, которая работает аналогично AzMan или NetSqlAzMan. Я предлагаю общий простой класс ClaimsAuthorizationManager, который может использовать каждое приложение. Этот класс вызывает общую службу WCF, которая, в свою очередь, использует серверную часть SQL для хранения бизнес-операций/задач и прав, которые пользователи имеют для них. Пользовательские объекты будут синхронизированы с AD, чтобы AD обеспечивала аутентификацию, утверждения, а моя пользовательская система предоставляла правила авторизации. Централизованность и уникальность этого сервиса помогают в достижении моей первой цели.

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

Любые советы, примеры или помощь высоко ценятся.


person CarlR    schedule 08.02.2013    source источник


Ответы (2)


Вы правы - поскольку AuthZ настолько специфичен для приложения, Microsoft не предоставила никаких конкретных реализаций.

Кажется, у вас уже есть очень конкретные идеи, как это должно работать. Почему бы вам не создать такой образец и не открыть его исходный код, чтобы вы могли собирать отзывы и, возможно, улучшать его на основе этого?

person leastprivilege    schedule 08.02.2013
comment
Спасибо за ответ Доминик. Хотя я, скорее всего, продолжу и сделаю это, я надеялся получить некоторое руководство по архитектуре такой системы и, в частности, по схеме данных. Думаю, я продолжаю спрашивать/искать, так как просто не могу поверить, что для этого нет ссылок. Такое ощущение, что я единственный, кто спрашивает об этом! Информации по этому вопросу так мало, и я не могу отделаться от ощущения, что упускаю что-то фундаментальное! - person CarlR; 08.02.2013
comment
Я действительно думаю, что многие люди писали что-то подобное. но для внутреннего употребления. Реализация общедоступной ссылки была бы хорошей. Дайте мне знать, когда у вас возникнут конкретные вопросы. - person leastprivilege; 09.02.2013

Некоторые мысли.

Роли — это хорошо понятный шаблон, например. универсальные модели данных.

ADFS может передавать группы как роли — ADFS: отправка групп как претензии. Затем вы можете использовать IsInRole или тег местоположения. Это может быть слишком упрощенно для вас?

ADFS может регистрировать аудит успеха или сбоя — «Свойства службы федерации» — События.

person rbrayb    schedule 11.02.2013
comment
Спасибо, я пытаюсь отвлечь нас от управления доступом на основе ролей, чтобы гарантировать, что приложения отделены от знаний о членстве в группе/роли. Если мы полагаемся на приложения, чтобы понять членство в роли, то для изменения этого требуются изменения в коде приложения, и нет централизованного места для отчета или контроля того, что может делать пользователь. Я думаю, что одним из преимуществ WIF и ClaimsAuthorizationManager является предоставляемая ими абстракция и возможность централизовать точку принятия решения о политике для вашего IAM. Я просто хочу, чтобы где-нибудь была эталонная архитектура! - person CarlR; 12.02.2013