Должна ли централизованная или децентрализованная логика авторизации?

Question

У нас есть система единого входа для аутентификации пользователей.

У нас есть дебаты между этими 2 вариантами:

1. Если мы централизовать разрешение каждого приложения в одной базе данных (или любой другой раствор) и получить информацию в запросе SSO

2. Каждый клиент веб-приложения должен управлять своей собственной логикой авторизации в своей локальной базе данных/схеме.

Answer 1

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

Вы уже внедрили SSO и, конечно же, используете пользовательский каталог в качестве бэкэнд для SSO для хранения идентификаторов пользователей. Это показывает, что вы успешно использовали внешнюю аутентификацию из защищаемых приложений. Вы когда-нибудь подумали о наличии базы данных имени пользователя/пароля для каждого приложения? Вы когда-нибудь подумали бы о написании логики для управления паролями, хэшами и т. Д.? Конечно нет! То же самое относится к авторизации.

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

Существует две основные модели для получения внешнего разрешения: либо вы используете модель управления доступом на основе ролей (RBAC), либо стремитесь к управлению доступом на основе атрибутов (ABAC). NIST содержит определения и еще как:

• NIST RBAC
• NIST ABAC

Многие каркасы приложений обеспечивают некоторую форму экстернализации. Возьмите Java Spring: он поставляется с Spring Security и Access Decision Managers (подробнее о Spring архитектуры here). PHP, Ruby, Python и .NET, но некоторые из них имеют свои собственные способы.

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

Идем дальше, вы даже можете рассмотреть возможность стандартизации внешней авторизации. Подобно тому, как у SSO есть свой стандарт (SAML), внешняя авторизация имеет XACML (eXtensible Access Control Markup Language), стандарт, определенный OASIS, очень похожий на SAML и поддерживаемый такими, как IBM, Oracle и Axiomatics, - где я работаю.

XACML предоставляет политический подход к экстернализированной мелкозернистой авторизации. Вы можете писать политики и применять их к любому числу приложений. И, конечно же, вы можете расширить свой уровень SSO с помощью XACML.

Преимущества использования экспортированных разрешения - и, в частности, стандартизированный по XACML - являются:

• консолидации логики авторизации: это проще и дешевле в обслуживании
• более высокий уровень безопасности: XACML более выразительным и теперь есть одно место, чтобы проверить, правильно ли реализована безопасность.
• Способность раскрывать новый бизнес: некоторые из клиентов, с которыми я имею дело, хотят разоблачить приложения в Интернете/третьих сторонах. Использование мелкомасштабной авторизации позволяет им контролировать, кто может делать то, что и при каких обстоятельствах.
• соответствие: посмотрите на мир, в котором мы живем сегодня. Мы должны соблюдать многие правила в зависимости от сферы нашей работы (банковское дело, страхование, медицинское ...). Эти правила трудно реализовать в коде, но их легко выразить в виде политик, которые обеспечивает именно XACML.

Если вы хотите узнать еще, я представил презентацию на Java и XACML на JavaZone 2013. Слайды: here.

Какое решение SSO вы используете? SiteMinder предоставляет вам API авторизации (ActivePolicy) для реализации более тонкой авторизации. Посмотрите на это.

Надеюсь, это поможет!

Answer 2

Я бы различал логику и данные, необходимые для авторизации.

Если вы ищете логику авторизации, это более специфично для приложения. Почему вы хотите централизовать логику? Возможно, у вас есть случай, когда одна и та же авторизационная логика используется в нескольких приложениях, и такая логика авторизации может быть изменена. Многим приложениям это не понадобится, хотя разработка приложения для экстернализации всей логики авторизации может не всегда быть жизнеспособным вариантом из-за требуемого времени и стоимости. Для этой цели необходим некоторый язык спецификации политики, и с каждым клиентским приложением следует использовать интерпретатор.

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

Назначение одного решения по другому - это не то, что мне нравится делать. Если мне когда-нибудь понадобится ответить «да/нет» на вопрос такого характера, я бы оценил и другие аспекты. Например,

1. Существующие приложения, их языки реализации, платформы, накладные расходы на модификацию и существующие механизмы авторизации.
2. Что именно должно быть централизованным (логическим, данным)?
3. Является ли степень обоснованности централизованной авторизации?
4. Накладные расходы на сеть и дополнительные задержки
5. Как это влияет на тестируемость систем и частей?
6. ... Этот список не закончится легко ...