Какова цель авторизации на основе претензий?

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

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

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

Единственное частичное объяснение, которое я видел, - это построение модели безопасности на основе претензий в WCF и дает два основных преимущества для претензий основанный на полномочиях: большая гибкость, и кто-то "ручатся", что информация в претензии верна. Когда вам это понадобится?

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

(EDIT: я пропустил третье пособие, указанное в статье: поддержка единого входа/федерации. Но не делает ли это аутентификация самостоятельно без участия авторизации?)

Ответ 1

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

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

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

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

Конечно, просто рассмотрение и реагирование на один набор претензий вместо того, чтобы понимать четыре, пять, десять разных и разрозненных систем аутентификации, похоже на действительно убедительное обещание для меня!

Ответ 2

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

Примечание. Претензии могут использоваться в рамках одного предприятия и обеспечивать следующие преимущества:

1) Доступ к грантам и отзывам не требует предоставления или отмены выделения

2) Таким образом, изменения мгновенно

3) Владельцы ресурсов могут определять область и требования к доступу, а не добавлять администраторов к группам, управляющим членством в группах, - это переводит решения управления доступом в руки людей, наиболее подходящих для принятия таких решений (владелец данных)

4) Это приводит к тому, что требуется меньшее количество групп и меньше членов в группах

5) Могут возникнуть проблемы с созданием отдельной группы для размещения большого сообщества, имеющего доступ (для Например, все сотрудники, работающие полный рабочий день, могут ознакомиться с кадровой политикой). Претензии устраняют эту проблему.

6) Аудит более информативен - причина, по которой проходил грант или отказ, отчетливо видна

7) Претензии поддерживают динамические атрибуты, такие как двухфакторная аутентификация, время суток или сетевые ограничения.

Есть много причин, но те приходят на ум. В скором времени будет представлено видео на www.cionsystems.com, которое демонстрирует это (отказ от ответственности - я там работаю и записываю видео - мне все равно нужно его публиковать). Кроме того, для справки, приложения и платформы, поддерживающие требования, включают SharePoint 2010 on, Windows 2012 (файловые ресурсы), Azure, многие сервисы SaaS (Facebook и Salesforce)

Кроме того, с претензиями вы можете смешивать информацию из нескольких источников (например, Facebook и ваш локальный AD) и т.д. - что становится все более важным

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

Претензии могут поступать из AD, таблиц баз данных, SAML, OAuth, алгоритмов, XACML или любого другого доверенного поставщика. Использование претензий требует немного набора - с приложениями и платформами, быстро развивающимися в этом пространстве.

Все лучшее,

Пол

Ответ 3

Контроль доступа на основе утверждений также помогает создавать управление доступом на основе атрибутов и управление доступом на основе политик. Если вы стандартизируете набор заранее согласованных претензий, которые могут быть назначены пользователям на основе их других атрибутов (например, у американского менеджера может быть претензия U_M, у европейского менеджера может быть претензия E_M). В среде, основанной на атрибутах и на основе политик, можно получить мелкозернистую авторизацию (также известную как мелкозернистые права) с использованием XACML. В этом случае у вас может быть разрешение, зависящее от того, кем является пользователь (претензии), а также то, что они хотят делать (информация о ресурсах) и при каких обстоятельствах (контексте).

CBAC с XACML позволит вам выражать такие правила, как:

Менеджеры
могут редактировать заметки, которые они создали сами, или отмечает, что их создаются прямые отчеты.

Ответ 4

Безопасность на основе ролей - ограниченная модель безопасности Авторизация:

 Based on role membership only

Защита, основанная на требованиях, намного более гибкая и выразительная Авторизация может быть:

Основываясь на членстве в ролях

В зависимости от возраста

Основываясь на географическом местоположении

Основываясь на балансе счета

Основываясь на размере

На основе заранее определенных уровней securtiy

На основе любой комбинации вышеперечисленных