Como configurar serviços RESTful seguras com WCF usando nome de usuário / senha + SSL

Question

Eu estou olhando para escrever um arquivo de configuração que permite serviços RESTful no WCF, mas eu ainda quero a capacidade de 'tocar em' o provedor de associação para o nome de usuário / autenticação de senha.

O abaixo é parte da minha configuração actual utilizando ligação basicHttp ou wsHttp w / out WS Segurança, como é que esta mudança w / REST serviços baseados?

    <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

ATUALIZAÇÃO 2012/01/23

Desde que eu escrevi esta pergunta eu vi uma abordagem muito melhor para garantir RESTO como serviços web em estado selvagem. Parecia complexa quando ouvi pela primeira vez sobre isso, mas a idéia é simples e em toda a web para ambos os serviços web e outros comunicação segura.

Ela exige o uso de chaves públicas / privadas.

1.) Cada usuário (cliente) do endpoint terá de se registar com o seu serviço web DESCANSO

• a.) Você dar a este usuário uma chave privada que não devem ser compartilhadas com qualquer
• b.) Você também gerar uma chave pública que pode ir sobre o fio em texto simples se necessário (este também será usado para identificar o cliente)

2.) Cada pedido das necessidades do usuário para gerar um hash para assinar o pedido

• a) Um exemplo deste olhar pode gostar:. Tecla + um timestamp + carga útil codificada privado (se pequeno o suficiente como uma simples informação do usuário a ser atualizado por exemplo)
• b.) Você tomar estes 3 (ou o que você decidiu sobre) e gerar um 1 way hash (usando hmac por exemplo)
• c.) No pedido a ser enviado através do fio você incluir a chave pública (para o lado do servidor sabe quem está a tentar enviar esta solicitação), o hash que foi gerado w / a chave privada, e o timestamp.

3.) O ponto final do servidor (o seu método REST) ??precisará gerar um hash usando os mesmos insumos utilizados no cliente. Esta etapa irá provar que cliente e servidor sabia uma chave privada que combinava com a chave pública passado junto com o pedido. (Isso em meio turno que o usuário enviar o pedido é legítimo como ninguém mais poderia saber a chave privada)

• a.) Pesquisar os clientes chave privada pela chave pública a ser repassada durante a solicitação

• b.) Toma as outras params (timestamp e a carga útil codificada) junto com a chave privada que você encontrou na etapa anterior e usar o mesmo algoritmo para gerar um hash 1 forma (novamente hmac é o que eu tenho visto usado no mundo real)

• c.) O que resulta 1 Way necessidades de hash para coincidir com o hash enviado através do fio, se não enviar de volta um 400 (ou o que http código que você julga ser um "mau pedido")

Answer 2

Aqui está um podcast em garantir serviços WCF descansar com o provedor de associação ASP.net:

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

Answer 3

Eu concordo com Darrel que os cenários de REST complexas sobre WCF são uma má idéia. Ele só não é bonito.

No entanto, Dominick Baier tem algum boas mensagens sobre isso em seu blog privilégio mínimo.

Se você gostaria de ver o suporte à autenticação WSSE com fallback para apoio FormsAuthenticationTicket em WCF, consulte a código fonte de BlogService .

Answer 4

Antes de continuar por este caminho de lutar para implementar REST sobre WCF, eu sugiro que você leia este post por Tim Ewald. I foi especialmente impactado pela declaração seguinte:

Eu não tenho certeza eu quero construir em um camada concebida para HTTP factor de sobre o topo de uma camada que foi desenhado para fator-lo.

Eu passei os últimos 12 meses desenvolvendo o material baseado em REST com o WCF e que a declaração tem provado ser tão verdadeiro e outra vez. IMHO o WCF traz para a mesa é superado pela complexidade introduz para fazer um trabalho REST.

Answer 5

Independentemente se a comunidade tem opiniões contra descansar sobre WCF (eu sou pessoalmente em cima do muro) Microsoft tomou um golpe para ele, http://msdn.microsoft.com/en-us/netframework/cc950529.aspx

Answer 6

Sim concordou com Moto, uma ligação fora do Starter Kit WCF é a coisa que eu vi mais próximo a autenticação de credenciais usando um costume HTTP cabeçalho ( http://msdn.microsoft.com/en-us/library/dd203052.aspx ).

No entanto, eu não poderia obter o exemplo indo.

Answer 7

Tente custombasicauth @ codeplex