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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

Одна из проблем - это некоторая комбинация "Не изобретенная здесь" и недоверие к внешним органам для (даже псевдоязычной) идентичности. Хорошая рецензия находится здесь:

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

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

Удачи!

Ответ 10

Согласитесь с точкой зрения Джозефа о том, что авторизация зависит от конкретного приложения.

Но помимо этого, авторизация на аутсорсинге также несет в себе серьезную проблему риска: поскольку авторизация сильно зависит от приложения и гранулирована, после того, как вы передаете авторизацию поставщику услуг, перенос или замена этого поставщика становится практически невозможной задачей. Вы на крючке безвозвратно.

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

Ответ 11

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

Теперь googling.