Существует ли причина, почему разработчики программного обеспечения не воплощают авторизацию?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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