Лучший механизм аутентификации для веб-сервисов Flex, ASP.NET и SOAP или REST?

Question

Я создаю веб-приложение, написанное на ASP.NET и Flex. Одна из моих самых больших проблем заключается в гибкой и удобной поддержке безопасности приложения. Эта проблема усугубляется, когда задействованы различные технологии. Я постараюсь описать то, что у меня есть ниже.

Сайт выложен следующим образом:

• / mydomain.com /
  • Login.aspx
  • Default.aspx (хост-приложение flex [.swf])
  • / Администрирование /
    • AddUsers.aspx
    • AddRoles.aspx
    • AddPermissions.aspx
    • и т.д ...
  • / Услуги /
    • SecurityService.asmx
    • MapService.asmx
    • PhotoService.asmx
    • и т.д ...

В настоящее время я использую аутентификацию по формам для защиты ресурсов на сайте. Все страницы / ресурсы, не находящиеся в папке / Services /, требуют аутентифицированного пользователя и будут перенаправлены на Login.aspx, если они еще не аутентифицированы. Страницы .asmx разрешают неаутентифицированным пользователям. Чтобы защитить эти ресурсы, я выбрасываю исключение в методе SOAP. Это позволяет избежать перенаправления страниц для веб-служб SOAP, которые не поддерживаются известными мне клиентами веб-служб SOAP. Наконец, SecurityService.asmx содержит метод Login, позволяющий приложению Flex войти в систему без перенаправления на страницу Login.aspx в случае истечения срока действия файла cookie по любой причине. Поскольку созданный файл cookie отправляется с любым запросом на сервер, включая запросы, поступающие из приложения Flex, это, кажется, работает довольно хорошо.

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

• Эта модель не будет работать, когда службы отделены от основного веб-сайта. Это недавно обнаруженное требование, и я считаю, что проверка подлинности с помощью форм не будет работать хорошо (если вообще будет) без гораздо большего изменения и хитрости.
• Клиентам, которым Flex предоставляет доступ к услугам. Некоторые из этих клиентов могут даже не использовать cookie-файлы. Если это так, эта модель сразу разваливается. Это не является непосредственным требованием, но известно, что это одна из долгосрочных целей.
• В конечном итоге (скорее, скорее, чем позже) мы перейдем к архитектуре на основе REST (вместо SOAP), поэтому любое решение должно работать для SOAP и REST.

Итак, мой вопрос.

Каковы наилучшие механизмы аутентификации и авторизации для защиты приложения, построенного на веб-службах ASP.NET, Flex и SOAP или REST?

Примечание: я активно изучаю OAuth; Однако мне трудно найти полные примеры для изучения. Кроме того, мне нужно иметь возможность фильтровать данные, возвращаемые для данного пользователя, на основе разрешений, которые есть у пользователя. Похоже, OAuth удаляет личность пользователя из токена. Таким образом, я не уверен, как OAuth применяется в детальной модели безопасности.

Answer 1

Другие могут не согласиться, но я на самом деле не вижу огромной проблемы с тем, чтобы справиться с этим, как вы сейчас; это, вероятно, как я справлюсь сам, по крайней мере, на начальном этапе. Так или иначе, даже в будущем, вы, вероятно, захотите информировать приложение Flex о состоянии аутентификации сеанса, поэтому, если это означает прямую проверку токена сеанса ASP.NET или какой-либо другой файл cookie, установленный вами при установить это, кажется, хороший и надежный путь.

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

Answer 2

См. Аутентификация веб-сервисов - лучшие практики?

Дейв Данкин писал:

Самый простой способ справиться с этим через Разнообразие платформ заключается в использовании HTTP базовая аутентификация и HTTPS для транспортный слой. WS-Security будет хорошо, если ваши потребности выходят за рамки простого имя пользователя / пароль, но поддержка будет варьироваться между платформ. HTTP-аутентификация поддерживается каждым достойным SOAP осуществление.

и моя Пользовательская базовая аутентификация HTTP для веб-служб ASP.NET в .NET 3.5 / VS 2008 .

Answer 3

Если вы переместите свои службы в другое место, то стандартный файл cookie проверки подлинности ASP.net можно использовать повторно, если оба веб-приложения имеют одинаковый ключ machineKey в файле web.config.

Насколько я знаю, FLEX будет хранить куки-файлы аутентификации asp.net, потому что он будет отправлять http-запросы через браузер, который будет передавать куки-файлы http (включая билет аутентификации asp.net), как обычный http-запрос.

Вы уже пытались защитить свой веб-сайт и службы с помощью обычной аутентификации asp.net?

Answer 4

Руководство по безопасности WCF , опубликованное на CodePlex, может вам помочь, если вы используете или можете использовать WCF.

Существует также Microsoft Web Services Enhancements (WSE) 3.0 , которая, как я считаю, реализует некоторые спецификации безопасности WS- *.

Надеюсь, это поможет.

Answer 5

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

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

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

Примечание: я бы не стал полагаться на исключение мыла для решения проблем аутентификации. Но вам не нужно беспокоиться о перенаправлении, если вы отправляете авторизационный токен или user / pass с запросами WS.

EDIT: RE: Комментарий- В идеале есть. Существуют продукты (Tivoli Access Manager), которые обслуживают эти потребности, но они дороги.

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

Answer 6

Признаюсь, я не очень много работаю с веб-сервисами, но как насчет запроса ключа доступа в качестве параметра мыльного заголовка? Любое клиентское приложение, которое может взаимодействовать с мыльным веб-сервисом, вероятно, имеет низкоуровневый API для изменения запроса на мыло, а использование ключа доступа позволяет (теоретически) ограничить использование сервиса. Google, Amazon и некоторые другие провайдеры используют этот тип аутентификации для своих веб-сервисов, и, похоже, он работает очень хорошо.

Эта статья может показаться хорошим началом ...