Как настроить безопасные службы RESTful с помощью WCF, используя имя пользователя / пароль + SSL
-
02-07-2019 - |
Вопрос
Я хочу написать конфигурационный файл, который позволяет использовать RESTful services в WCF, но я все еще хочу иметь возможность "подключаться" к поставщику членства для аутентификации по имени пользователя / паролю.
Приведенное ниже является частью моей текущей конфигурации с использованием привязки basicHttp или wsHttp без защиты WS, как это изменится без служб на основе REST?
<bindings>
<wsHttpBinding>
<binding name="wsHttp">
<security mode="TransportWithMessageCredential">
<transport/>
<message clientCredentialType="UserName" negotiateServiceCredential="false" establishSecurityContext="false"/>
</security>
</binding>
</wsHttpBinding>
<basicHttpBinding>
<binding name="basicHttp">
<security mode="TransportWithMessageCredential">
<transport/>
<message clientCredentialType="UserName"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="NorthwindBehavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceAuthorization principalPermissionMode="UseAspNetRoles"/>
<serviceCredentials>
<userNameAuthentication userNamePasswordValidationMode="MembershipProvider"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
Решение 7
ОБНОВЛЕНИЕ 23.01.2012
С тех пор как я написал этот вопрос, я видел гораздо лучший подход к обеспечению безопасности REST, такой как веб-сервисы в дикой природе.Это звучало сложно, когда я впервые услышал об этом, но идея проста и распространяется по всему Интернету как для веб-сервисов, так и для других безопасных коммуникаций.
Это требует использования открытых / закрытых ключей.
1.) каждому пользователю (заказчику) конечной точки необходимо будет зарегистрироваться в вашем веб-сервисе REST
- а.) вы даете этим пользователем закрытого ключа, что не следует делиться с любой
- б.) вы также генерируете открытый ключ, который при необходимости может передаваться по сети в виде обычного текста (это также будет использоваться для идентификации клиента)
2.) каждый запрос от пользователя должен генерировать хэш для подписи запроса
- a.) Один из примеров этого может выглядеть следующим образом:закрытый ключ + временная метка + закодированная полезная нагрузка (если она достаточно мала, например, для обновления простой информации о пользователе)
- б.) вы берете эти 3 (или все, что вы выбрали) и генерируете односторонний хэш (например, используя hmac)
- c.) в запросе, отправляемом по проводам, вы включаете открытый ключ (чтобы серверная сторона знала, кто пытается отправить этот запрос), хэш, который был сгенерирован с помощью закрытого ключа, и временную метку.
3.) конечной точке сервера (вашему методу REST) потребуется сгенерировать хэш, используя те же входные данные, которые используются на клиенте.Этот шаг докажет, что и клиент, и сервер знали закрытый ключ, который соответствовал открытому ключу, переданному вместе с запросом.(это, в свою очередь, означает, что пользователь, отправляющий запрос, является законным, поскольку никто другой не мог знать закрытый ключ)
a.) поиск закрытого ключа клиента по открытому ключу, передаваемому во время запроса
б.) возьмите другие параметры (временную метку и закодированную полезную нагрузку) вместе с закрытым ключом, который вы нашли на предыдущем шаге, и используйте тот же алгоритм для генерации одностороннего хэша (опять же, hmac - это то, что я видел используемым в реальном мире)
- c.) полученный односторонний хэш должен соответствовать хэшу, отправленному по проводу, если нет, отправьте обратно 400 (или любой другой http-код, который вы сочтете "неправильным запросом")
Другие советы
Вот подкаст об обеспечении WCF и REST сервисов с помощью поставщика членства ASP.NET :
http://channel9.msdn.com/posts/rojacobs/endpointtv-Securing-RESTful-services-with-ASPNET-Membership/
Я согласен с Даррелом в том, что сложные сценарии REST поверх WCF - плохая идея.Это просто некрасиво.
Однако у Доминика Байера есть некоторые хорошие посты об этом он написал в своем блоге "наименьшие привилегии".
Если вы хотите увидеть поддержку аутентификации WSSE с возвратом к поддержке FormsAuthenticationTicket в WCF, ознакомьтесь с исходный код BlogService.
Прежде чем вы продолжите идти по этому пути борьбы за внедрение REST поверх WCF, я предлагаю вам прочитать это сообщение Тима Эвальда.На меня особенно повлияло следующее заявление:
Я не уверен, что хочу использовать слой, предназначенный для учета HTTP поверх слоя, который был разработан для его учета.
Я потратил последние 12 месяцев на разработку материалов на основе REST с помощью WCF, и это утверждение доказывало свою истинность снова и снова.ИМХО, то, что WCF привносит в таблицу, перевешивается сложностью, которую он вносит для выполнения работы REST.
Независимо от того, есть ли у сообщества мнения против REST в WCF (Лично я нахожусь в затруднительном положении) Microsoft приложила к этому руку, http://msdn.microsoft.com/en-us/netframework/cc950529.aspx
Да, согласен с Moto, ссылка на стартовый набор WCF - это самое близкое, что я видел для аутентификации учетных данных с использованием пользовательского заголовка HTTP (http://msdn.microsoft.com/en-us/library/dd203052.aspx).
Однако я не смог привести пример в действие.
Попробуй customb basicauth @ codeplex