Советы по безопасности OpendID для Asp.net - PullRequest
Новая
       17

Советы по безопасности OpendID для Asp.net

1 голос
/ 26 февраля 2010

Я только начинаю с OpenID в приложении Asp.net MVC, и мне было интересно, каковы некоторые подводные камни при использовании OpenID. Причина, по которой я спрашиваю, заключается в том, что я прочитал много предупреждений при использовании некоторых реализаций OpenID. В основном это что-то вроде «Не используйте эту библиотеку! Вам просто нужно изменить одно слово в URL, и ваш сайт открыт для всех !!!!»

Скорее всего, в конечном итоге я буду использовать DotNetOpenAuth, но некоторые новички в качестве новичка кажутся немного чужими. Это также одна из причин, почему я задал этот вопрос, потому что незнание не сделает мое приложение очень безопасным.

Поскольку нет правильного ответа, я надеюсь, что сделать этот вопрос «сообщество вики» - это то, что нужно делать. Если вопрос такого рода не разрешен, я сразу его удалю.

Заранее спасибо,

Pickels

Ответы [ 2 ]

1 голос
/ 26 февраля 2010

Я не могу говорить о существующих проектах .NET, но могу дать объяснение основам для начинающих. Хотя есть некоторые крайние случаи и необязательные функциональные возможности, основной процесс не сложен для понимания. Поставщики услуг с поддержкой OpenID («Проверяющие стороны» или RP) эффективно выгружают функцию проверки пароля при аутентификации на сторонний веб-сайт («Identity Provider», или IdP). URL (специфичный для конечного пользователя) для такого IdP указывается конечным пользователем, и (с точки зрения RP) этот URL является «Идентификатором» конечного пользователя. RP выполняет серверный вызов URL-адреса идентификатора, чтобы получить токен активности, а затем перенаправляет браузер на URL-адрес идентификатора. Теперь конечный пользователь взаимодействует с IdP, и когда IdP удовлетворяется, он возвращает браузер обратно в RP с некоторой информацией, прикрепленной к строке запроса, чтобы указать на успех. Вуаля.

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

Много раз (не здесь, в SO) RP фактически делает Идентификатор общедоступным во всей службе, например. как имя пользователя конечного пользователя. Поэтому модно использовать тщеславный URL-адрес или URL-адрес блога или что-то более значимое, чем http://superopenidprovider.com/adjad9va8ivasdlkjnq8t7. Таким образом, существует концепция делегирования IdP, посредством которой конечный пользователь, который включает на своей домашней странице / блоге соответствующие теги LINK для http://superopenidprovider.com/adjad9va8ivasdlkjnq8t7,, может использовать URL своей домашней страницы / блога в качестве своего идентификатора. RP должны знать об этой функции и предпринимать соответствующие действия.

Концепции высокого уровня

Примерно из Википедия . Это более концептуально, чем ответ Эндрю.

  • Конечный пользователь Человек, который хочет подтвердить свою личность поставщику услуг.
  • Идентичность Информация о поставщике услуг, относящаяся к одному конечному пользователю. То есть все, что идентифицирует конечный пользователь и хочет защитить.
  • Идентификатор Конкретный URL-адрес конечного пользователя, предоставленный конечным пользователем, с помощью которого можно инициировать аутентификацию OpenID.
  • Проверяющая сторона (RP) Поставщик услуг, использующий OpenID для определения правдивости заявления о личности конечного пользователя.
  • Веб-сайт провайдера идентификации (IdP) , который может отвечать на запросы аутентификации OpenID от проверяющих сторон, как правило, с помощью запроса / ответа на основе пароля конечному пользователю через веб-формы и файлы cookie. IdP обычно поддерживают несколько пользователей и, таким образом, позволяют конечным пользователям регистрировать и управлять идентификаторами через сайт. Тем не менее, человек может разместить свой собственный IdP, который только аутентифицируется.
1 голос
/ 26 февраля 2010

DotNetOpenAuth не является одной из тех библиотек, которые «меняют одно слово, и оно сломано». Это хороший для использования.

Что касается терминологии:

  • ClaimedIdentifier - это новое имя пользователя. Относитесь к нему с учетом регистра и убедитесь, что ваша база данных выполняет поиск с учетом регистра, когда вы просматриваете записи пользователей на ее основе. Не учитывайте URL-адреса http и https, которые в остальном идентичны одному и тому же пользователю - их следует считать совершенно разными.
  • Идентификатор, предоставленный пользователем является литеральной строкой, введенной пользователем в поле OpenID (если оно есть). Никогда, никогда не относитесь к этому как к авторитетному и не принимайте решения по безопасности на его основе. Подождите, пока вы не получите ClaimedIdentifier из ответа и примете решение на его основе, а также ProviderEndpoint.
  • OP Endpoint (он же конечная точка провайдера) - это URL-адрес конечной точки OpenID провайдера OpenID, и вы можете принять решение по этому вопросу, если хотите доверять только определенным провайдерам.
  • Претензии , такие как адрес электронной почты и полное имя пользователя, могут поступать от поставщика, если вы запрашиваете эти атрибуты. Но никогда не доверяйте этому как правильному, если претензии не исходят от конечной точки OP, которой вы доверяете.
...