Comment configurer des services RESTful sécurisés avec WCF en utilisant nom d'utilisateur / mot de passe + SSL

Question

Je cherche à écrire un fichier de configuration qui autorise les services RESTful dans WCF, mais je souhaite tout de même pouvoir utiliser le fournisseur d'appartenance pour l'authentification par nom d'utilisateur / mot de passe.

Ce qui suit fait partie de ma configuration actuelle utilisant la liaison basicHttp ou wsHttp avec WS Security. Comment cela changera-t-il les services basés sur 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

UPDATE 23/01/2012

Depuis que j'ai écrit cette question, j'ai constaté une approche bien meilleure pour sécuriser REST comme des services Web à l'état sauvage. La première fois que j'en ai entendu parler, cela semblait complexe, mais l'idée est simple et diffusée sur le Web, tant pour les services Web que pour les autres communications sécurisées.

Cela nécessite l'utilisation de clés publiques / privées.

1.) chaque utilisateur (client) du système d'extrémité devra s'enregistrer auprès de votre service Web REST

• a.) vous donnez à cet utilisateur une clé privée qui ne devrait pas être partagée avec n'importe qui
• b.) vous générez également une clé publique qui peut passer par le fil en clair si nécessaire (cela servira également à identifier le client)

2.) chaque demande de l'utilisateur doit générer un hachage pour signer la demande

• a.) Un exemple de ceci pourrait ressembler à: clé privée + un horodatage + une charge encodée (si petit comme une simple information utilisateur à mettre à jour par exemple)
• b.) vous prenez ces 3 (ou ce que vous avez décidé) et générez un hachage à 1 voie (en utilisant hmac par exemple)
• c.) dans la demande envoyée par le fil, vous incluez la clé publique (pour que le serveur sache qui tente d'envoyer cette demande), le hachage généré avec la clé privée et l'horodatage.

3.) le noeud final du serveur (votre méthode REST) ??devra générer un hachage en utilisant les mêmes entrées que celles utilisées sur le client. Cette étape prouvera que le client et le serveur connaissaient une clé privée correspondant à la clé publique transmise avec la demande. (Cela signifie à son tour que l'utilisateur qui envoie la demande est légitime, car personne d'autre ne pourrait connaître la clé privée).

• a.) recherchez la clé privée du client à l'aide de la clé publique transmise lors de la demande

• b.) prenez les autres paramètres (horodatage et la charge codée) avec la clé privée trouvée à l'étape précédente et utilisez le même algorithme pour générer un hachage à 1 voie (encore hmac est ce que j'ai vu utilisé dans le monde réel)

• c.) le hachage à sens unique résultant doit correspondre au hachage envoyé par le fil, sinon renvoyer un 400 (ou le code http que vous considérez comme une "requête incorrecte")

Answer 2

Voici un podcast sur la sécurisation des services WCF REST avec le fournisseur d’adhésion ASP.net:

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

Answer 3

Je suis d’accord avec Darrel pour dire que les scénarios REST complexes sur WCF sont une mauvaise idée. Ce n’est pas beau.

Cependant, Dominick Baier a publié des bons articles sur son blog le plus confidentiel. / p>

Si vous souhaitez voir la prise en charge de l'authentification WSSE avec le repli sur la prise en charge de FormsAuthenticationTicket sur WCF, consultez le code source de BlogService. .

Answer 4

Avant de continuer à vous battre pour implémenter REST over WCF, je vous suggère de lire ceci posté par Tim Ewald. J'ai été particulièrement touché par la déclaration suivante:

  

Je ne suis pas sûr de vouloir construire sur un   couche conçue pour prendre en compte HTTP   haut d'une couche qui a été conçue pour   factorisez-le.

Au cours des 12 derniers mois, j'ai développé des éléments basés sur REST avec WCF et cette affirmation s’est révélée si vraie encore et encore. IMHO, ce que WCF apporte à la table est compensé par la complexité qu’il introduit pour le travail REST.

Answer 5

Peu importe si la communauté a des opinions contre REST on WCF (personnellement, je suis sur la clôture) Microsoft a fait un geste, http://msdn.microsoft.com/en-us/netframework/cc950529.aspx

Answer 6

Oui, je suis d’accord avec Moto. Un lien dans le kit de démarrage de la WCF est la solution la plus proche de l’authentification des informations d’identité à l’aide d’un en-tête HTTP personnalisé ( http://msdn.microsoft.com/en-us/library/dd203052.aspx ).

Cependant, je n'ai pas pu obtenir l'exemple.

Answer 7

Essayez custombasicauth @ codeplex