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

Question

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

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

Answer 1

Вот подкаст о защите служб WCF REST с поставщиком членства ASP.net:

http://channel9.msdn.com/posts/rojacobs/endpointtv-Securing-RESTful-services-with-ASPNET-Membership/

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

• c.) Результирующий однонаправленный хеш должен соответствовать хешу, отправленному по проводной связи, если не отправлять обратно 400 (или любой другой http-код, который вы считаете «неправильным запросом»)

Answer 4

Попробуйте custombasicauth @ codeplex

Answer 5

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

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

Answer 6

Независимо от того, есть ли у сообщества мнения против REST по поводу WCF (я лично нахожусь на заборе) Microsoft провела на этом проверку, http://msdn.microsoft.com/en-us/netframework/cc950529.aspx

Answer 7

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

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

Последние 12 месяцев я потратил на разработку материалов на основе REST с WCF, и это утверждение снова и снова подтверждается. ИМХО, что WCF приносит на стол, перевешивается сложностью, которую он вводит для выполнения работы REST.