Как настроить безопасные службы RESTful с помощью WCF с использованием имени пользователя/пароля + SSL

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

Ниже приведена часть моей текущей конфигурации с использованием привязки basicHttp или wsHttp w/out WS Security, как это изменится с помощью служб на основе 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>

ОТВЕТЫ

Ответ 1

ОБНОВЛЕНИЕ 01/23/2012

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

Для этого требуется использование открытых/закрытых ключей.

1.) каждому пользователю (клиенту) конечной точки необходимо будет зарегистрироваться в веб-службе REST

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

2.) каждый запрос от пользователя должен генерировать хеш для подписи запроса

  • a.) Одним из примеров может быть: private key + timestamp + закодированная полезная нагрузка (если она достаточно мала, например простая информация о пользователе, которая должна быть обновлена)
  • b.) вы берете эти 3 (или все, что вы решили), и генерируете хэш 1-го уровня (например, с помощью hmac)
  • c.) в запросе, отправляемом по проводу, вы включаете открытый ключ (так что серверная сторона знает, кто пытается отправить этот запрос), хэш, который был сгенерирован с закрытым ключом, и метку времени.

3.) конечная точка сервера (ваш метод REST) ​​должна будет генерировать хэш, используя те же самые входы, которые используются на клиенте. Этот шаг докажет, что и клиент, и сервер знали закрытый ключ, который соответствовал открытому ключу, переданному вместе с запросом. (это, в свою очередь, означает, что пользователь, отправляющий запрос, является законным, поскольку никто другой не может знать закрытый ключ)

  • a.) искать закрытый ключ клиентов открытым ключом, который передается во время запроса

  • b.) возьмите другие параметры (временную метку и закодированную полезную нагрузку) вместе с секретным ключом, который вы нашли на предыдущем шаге, и используйте тот же алгоритм для генерации 1-х точечного хэша (снова hmac - это то, что я видимый в реальном мире)

  • c.) полученный 1-х ходовой хэш должен соответствовать хешу, отправленному по проводу, если не отправить обратно 400 (или любой другой http-код, который вы считаете "плохим" ).

Ответ 3

Я согласен с Даррелом в том, что сложные сценарии REST над WCF - плохая идея. Это просто некрасиво.

Однако у Доминика Байера есть хорошие сообщения об этом в его блоге с наименьшими привилегиями.

Если вы хотите, чтобы поддержка WSSE-аутентификации поддерживалась с поддержкой резервного копирования FormsAuthenticationTicket в WCF, проверьте исходный код BlogService.

Ответ 4

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

Я не уверен, что хочу построить слой, предназначенный для включения HTTP в верх слоя, который был разработан для исключить его.

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

Ответ 6

Да, согласен с Moto, связь с WCF Starter Kit - это самое близкое, что я видел для аутентификации учетных данных с использованием настраиваемого HTTP-заголовка (http://msdn.microsoft.com/en-us/library/dd203052.aspx).

Однако я не мог получить пример.