Есть ли причина, по которой разработчики программного обеспечения не экстернализуют авторизацию?

Question

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

Причина в недостаточной осведомленности или что-то еще? Как вы ожидаете узнать о XACML подходах к разработке программного обеспечения?

Обратите внимание, что я спрашиваю об авторизации, а не об аутентификации.

Answer 1

Я думаю, что перспектива внешней авторизации гораздо сложнее, чем внешняя аутентификация (OpenID, CardSpace и т. Д.). Это в основном связано с тем, что авторизация гораздо более специфична для конкретного приложения. То, что человеку А разрешено делать в моем приложении, он, возможно, не сможет сделать в вашем приложении, и это даже при условии, что между моим приложением и вашим приложением существует некоторая общая параллель, которой, скорее всего, не будет.

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Ниже приведены мои комментарии по OpenID в качестве службы аутентификации.

1) Как было указано, авторизация! = Аутентификация. OpenID обрабатывает аутентификацию, но владелец веб-приложения по-прежнему имеет полный контроль над правами, назначенными этому логину. Это положительно, но путаница в этом отрицательна.

2) Я не могу найти ссылку, но OpenID открыт для социальной инженерии / main в середине / фишинговых атак. Поставщики пытаются предотвратить это (идентификационные изображения, сертификаты браузера, подтверждение обратного вызова и т. Д.), Но это не помогает, когда на сайте черной шляпы появляется диалоговое окно / страница с надписью «введите имя пользователя и пароль OpenID» и гениальность пользователь соответствует.

3) Каждый поставщик федеративного идентификатора имеет возможность (и некоторые назовут ответственность) отслеживать все действия своих пользователей, независимо от того, для какого сайта они используют идентификатор. Вот почему Google и Yahoo очень хотят предоставить федеративных идентификаторов, но не так рады, что потребляют их.

4) В противоположность вышеприведенному комментарию, как правило, использование OpenID уменьшает барьер для регистрации, особенно когда полезный пользовательский интерфейс указывает, что новый пользователь, вероятно, уже имеет OpenID. Это еще более верно, когда вы используете комбинированное решение OpenID / OAuth, такое как RPX.

Так что, с моей точки зрения, риски использования OpenID лежат на пользователе, а не на веб-сайте. Я не могу предотвратить фишинг пользователя, заставив его вспомнить еще один идентификатор пользователя и пароль. Кроме того, Black Hats не нужно делать ничего более гнусного, чем хранить пароли пользователей для своего сайта в виде простого текста, чтобы получить доступ к другим учетным записям пользователя. Сколько людей используют разные пароли для каждого веб-сайта, на котором выполняется вход?

Answer 5

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

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

Answer 6

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

Производительность - еще одна проблема. Это можно увидеть, получив реализацию XACML от Sun и использовав ее для внешней авторизации. Вы несете сетевые расходы по обеим сторонам запроса, которые (в зависимости от того, как вы разрабатываете запрос / ответ и т. Д.) Могут значительно превышать фактическую стоимость решения об авторизации. Встраивайте это в COTS-приложение, где у вас меньше свободы для оптимизации производительности, и все становится еще хуже.

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

Answer 7

Одной из проблем является некоторая комбинация «Не изобретено здесь» и недоверие сторонним властям к (даже псевдономной) идентичности. Хорошая статья здесь:

• Доверяете ли вы своему провайдеру идентификации?

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

Answer 8

Несколько причин:

1. Как показали некоторые комментарии, существует общее мнение о том, что «авторизация является локальной», что подразумевает, что существует небольшой потенциал от повторного использования дорогих для поддержания в высоком качестве «предметных атрибутов», необходимых для важные решения доступа. (Я считаю, что существует большой потенциал повторного использования, поскольку некоторые законы / правила широко применяются, но полное обсуждение этого вопроса слишком длинное для этого формата.)
2. Недостаток инфраструктуры данных: для применения основанного на политиках контроля доступа между организациями (я использую / доверяю данным другой организации («AuthZ») для разблокировки доступа к моим данным) требуется, как минимум, понимание семантики атрибута (что такое «сотрудник правоохранительных органов»? что такое «гражданин США».) После этого было бы неплохо иметь простые для понимания стандарты качества атрибутов и их сертификацию третьей стороной. (Некоторые могут заметить, что эти требования аналогичны требованиям к совместимости PKI: как это происходит? И это только для одного фрагмента данных плюс вспомогательные материалы.)
3. Влияние на роли / обязанности: экстернализация авторизации, будь то «роли» или «атрибуты» или «атрибуты с цифровой политикой», означает, что локальный «владелец данных» теряет контроль над ресурсом. Он также выполняет значительную работу и отвечает за ведение списков пользователей. Подобные изменения повышают эффективность реализации внешнего AuthZ от технической проблемы до организационного вопроса со стороны политики.
4. Большинство организаций не знают и не записали свои политики. Доступ может быть «кто спрашивает» или «кто спрашивает, и мне нравится» или «кто может дать мне что-то, например, доступ к своим данным». Реальные применяемые правила могут быть довольно уродливыми, когда их заставляют открыто выражать их на языке политики. И навыки, необходимые для хорошего воспроизведения написанных политик в цифровых политиках, тоже не растут на деревьях. На самом деле набор навыков - бизнес-аналитик или юрист, а не ИТ-специалист, и инструменты для таких людей редки или вообще отсутствуют.
5. Если у вас есть надежное правило политики, вы, вероятно, обнаружите, что атрибуты, необходимые для его обработки, не существуют - обычно это не то, что вы уже нашли в AD. Номер телефона НЕ полезен в качестве атрибута AuthZ, и даже «Организация», вероятно, не подходит для большинства законов или правил, которые вы можете задокументировать. Это даже не упоминает обходные пути и приближения, которые вы должны внедрить (и получить одобрение), чтобы выразить требования политики, такие как «вероятная причина».
6. Относительно легко понять, но все же реально, что многие очень распространенные приложения COTS не поддерживают внешнюю авторизацию, и многие разработчики приложений не привыкли к экстернализации, и поэтому (а) попытаются отговорить вас от этого; или (б) выучить его на копейки, и делать это плохо.

---

Звучит довольно плохо, верно? Итак, позвольте мне в заключение сказать, что я думаю, что игра стоит свеч, несмотря на все это. Список потенциальных выгод для другого поста в другое время.

Удачи!

Answer 9

Лично для меня это первое, что я когда-либо слышал о внешней авторизации. Так что это может быть просто недостаточная осведомленность.

Погуглив сейчас ..

Answer 10

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