Детальная авторизация для веб-приложений

Question

У меня есть приложение на C # .net, которое обслуживает как внутренних пользователей компании, так и внешних клиентов.Мне нужно сделать детальную авторизацию, например, кто получает доступ к какому ресурсу.Поэтому мне нужно что-то вроде основанной на ресурсах или атрибутах, а не авторизации на основе ролей.

Мне приходит на ум следующее:

1. Реализация собственного механизма авторизации итаблицы sql для моего приложения .net
2. Использование / реализация стандартного механизма, например, программного обеспечения, в котором реализован XACML (например, Axiomatics)

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

Проблема второго подхода заключается в том, что он потенциально медленнее (из-за дополнительных вызовов, необходимых для каждого ресурса).Также я не уверен, насколько широко стандартные приложения, такие как XACML, поддерживаются приложениями на рынке, чтобы упростить будущие интеграции.

Итак, в целом Каковы хорошие практики для детальной авторизации для веб-приложений, которые должны обслуживать как внутренних пользователей, так и внешних клиентов?

Answer 1

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

Обзор XACML - это хороший путь. ТК очень активен, и такие активные участники, как Boeing, EMC, Администрация ветеранов, Oracle и Axiomatics.

Архитектура XACML гарантирует, что вы можете получить желаемую производительность. Поскольку правоприменение (PEP) и механизм принятия решений (PDP) слабо связаны, вы можете выбрать, как они взаимодействуют, какой протокол они используют, использовать ли несколько решений и т. Д. ... Это означает, что у вас есть выбор: соответствует вашим потребностям в производительности.

Существует также стандартный интерфейс PDP, определенный в профиле SAML для XACML. Это гарантирует вам контроль доступа «на будущее», когда вы не привязаны к какому-либо конкретному решению поставщика.

Контроль доступа для веб-приложений Вы можете просто вставить PEP для .Net веб-приложений, используя фильтры HTTP в ISAPI и ASP.NET. У Axiomatics есть один готовый продукт для этого.

Текущие реализации Если вы зайдете на страницу клиентов Axiomatics, вы увидите, что у них есть Paypal, Bell Helicopter и многое другое. Таким образом, XACML действительно является реальностью и может использоваться для очень больших развертываний (сотни миллионов пользователей).

Кроме того, Datev eG, ведущий поставщик финансовых услуг, использует реализацию .Net PDP компании Axiomatics для своих услуг / приложений. Поскольку в этом случае встроен .Net PDP, производительность является оптимальной.

В противном случае вы всегда можете выбрать из готовых PEP для .Net интеграцию с любым PDP, например, с сервисом авторизации XACML на основе SOAP.

Высокий уровень производительности с XACML В июле прошлого года на конференции Gartner «Catalyst» компания Axiomatics объявила о выпуске своего последнего продукта - обратного запроса Axiomatics, который поможет вам справиться с «миллиардной задачей». Он нацелен на контроль доступа к источникам данных, а также к RIA. В нем используется чистое решение XACML, поэтому оно остается совместимым с другими решениями.

На самом деле, в ближайшее время Kuppinger Cole проведет вебинар на эту тему: http://www.kuppingercole.com/events/n10058

Смотрите пресс-релиз Axiomatics ARQ здесь: http://www.axiomatics.com/latest-news/216-axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services.html

Answer 2

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

Хорошей идеей является вывод решения об авторизации из вашего приложения.с архитектурной точки зрения.Вывод решения authz дает вам огромную гибкость для изменения критериев доступа на лету без необходимости выключения веб-службы или перенастройки самого веб-сервера.Отключение веб-интерфейса от механизма authz позволяет независимо масштабировать каждый из них в соответствии с нагрузкой и типами трафика вашего приложения и позволяет использовать механизм authz для нескольких приложений.

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

Например, в системе Keystone компании BiTKOO пользовательские атрибуты могут кэшироваться на веб-сервере для каждой пользовательской сессии, так что на самом деле только один внутренний запрос сети включается в запрос первой страницы как часть установленияЛогин пользователя.Последующие запросы страниц (в течение срока действия кэшированных учетных данных, обычно 5 минут или около того) могут обрабатываться веб-сервером без повторного обращения к службе authz.Это хорошо масштабируется в облачных веб-фермах и основано на стандартах XACML.