Cet article a fait l'objet d'une traduction automatique.
Fondations
Sécuriser le bus de service .NET
Juval Lowy
Téléchargement de code disponible à partir du MSDN Code Gallery
Parcourir le code en ligne
Contenu
Configuration de l'authentification
Authentification CardSpace
Authentification par mot de passe
Authentification par certificat
Aucune authentification
Sécurité de transfert
Sécurité du transport
Sécurité des messages
Liaison de relais TCP et sécurité de transfert
Liaison de relais Web et sécurité de transfert
Liaison de relais à sens unique et sécurité de transfert
Rationalisation de la sécurité de transfert
Dans ma colonne avril 2009, j'ai présenté le groupe de services .NET et décrit comment vous pouvez utiliser liaisons de relais pour connecter votre application et les clients sur presque tous les limites de réseau. Toutefois, si simplement tout le monde était autorisé à relayer des messages à votre service ou si n'importe quel service a pu recevoir vos appels client, le service relais serait une proposition dangereuse. Vous devez protéger le transfert de message à partir du client au service via le service de relais. Dans cet article, je vous montrerai comment sécuriser le groupe de services .NET et de fournir certaines classes d'assistance et les utilitaires pour automatiser les nombreux détails de la.
Le groupe de services .NET impose que le service doit toujours authentifier pour recevoir des messages relayées. Clients, peuvent en revanche, l'ou peut ne pas authentifient eux-mêmes. En général (et par défaut), les clients s'authentifient, mais le service relayé peut décider de dispenser l'authentification du bus de services .NET du client.
Le groupe de services .NET propose trois différents mécanismes d'authentification, CardSpace, mot de passe ou certificat, et il est à l'administrateur de solution pour associer ces utilisant la page solution illustrée La figure 1 .
Figure 1 Options de configuration de solution authentification
Une solution unique peut prendre en charge plusieurs options d'authentification et pour chaque option de l'administrateur peut ajouter plusieurs informations d'identification. Par exemple, l'administrateur peut configurer trois mots de passe, les deux cartes et un seul certificat. Présenter l'un des ces informations d'identification est suffisant pour s'authentifier auprès du service de relais. En outre, le service et le client peuvent utiliser différentes méthodes d'authentification. Par exemple, le service peut utiliser un mot de passe et le client un certificat.
Configuration de l'authentification
L'enum TransportClientCredentialType, illustré ici, représente les options d'informations d'identification disponibles :
public enum TransportClientCredentialType
{
CardSpace,
UserNamePassword,
X509Certificate
Unauthenticated,
FederationViaCardSpace,
AutomaticRenewal
}
Dans TransportClientCredentialType, client fait référence à un client du groupe de services .NET — c'est-à-dire que le client et le service relayé.
Le mécanisme d'authentification par défaut et les informations d'identification eux-mêmes sont configurées à l'aide un comportement de point de terminaison appelé TransportClientEndpointBehavior, défini dans La figure 2 .
La figure 2 TransportClientEndpointBehavior
public class TransportClientEndpointBehavior : IEndpointBehavior
{
public TransportClientCredentials Credentials
{get;}
public TransportClientCredentialType CredentialType
{get;set;}
}
public class TransportClientCredentials
{
public X509CertificateCredential ClientCertificate
{get;}
public UserNamePasswordCredential UserName
{get;}
}
À l'aide d'un comportement de point de terminaison (par opposition à un comportement de service) offre deux avantages. Tout d'abord, un service ordinateur hôte pouvez choisir un mécanisme d'authentification différente pour chaque point de terminaison. Ensuite, un comportement de point de terminaison offre un modèle de programmation unifié pour le client et le service car le client dispose uniquement des comportements de point de terminaison.
Authentification CardSpace
CardSpace est le type d'informations d'identification par défaut utilisé par toutes les liaisons de relais. Lorsque le client ou l'ordinateur hôte utilise CardSpace authentification, l'utilisateur est invité à fournir une carte sur l'ouverture du ordinateur hôte ou le proxy. Une fois que l'utilisateur a fourni la carte, il est fourni dans le message demande de connexion pour le service de relais. Évidemment, une telle approche est idéale pour les applications interactives. Ces invites, seront toutefois ennuyer l'utilisateur si elles se produisent chaque fois que l'utilisateur ouvre un nouveau proxy ou un ordinateur hôte. Heureusement, mis en cache les informations d'identification dans le domaine d'application et l'utilisateur n'est pas invité à nouveau tant qu'il accède à la même adresse de point de terminaison.
Authentification par mot de passe
Comme l'authentification CardSpace, l'authentification par mot de passe est idéale pour une application interactive, généralement en conjonction avec une boîte de dialogue de connexion. Toutefois, il est inutile d'inviter l'utilisateur d'entrer un nom d'utilisateur car c'est toujours le nom de la solution. Une fois que l'utilisateur a fourni le mot de passe, vous devez fournir par programme le nom de solution et le mot de passe pour le TransportClientEndpointBehavior.
Sur le côté ordinateur hôte, vous devez instancier un nouvel objet TransportClientEndpointBehavior et affectez à la propriété CredentialType TransportClientCredentialType.UserNamePassword. Les informations d'identification eux-mêmes sont fournies pour la propriété Credentials. Vous ajoutez ce comportement à chaque point de terminaison d'ordinateur hôte qui utilise le service relais, comme indiqué dans la figure 3 .
La figure 3 destinée à l'hôte avec le mot de passe solution
TransportClientEndpointBehavior behavior =
new TransportClientEndpointBehavior();
behavior.CredentialType = TransportClientCredentialType.UserNamePassword;
behavior.Credentials.UserName.UserName = "MySolution";
behavior.Credentials.UserName.Password = "MyPassword";
ServiceHost host = new ServiceHost(typeof(MyService));
foreach(ServiceEndpoint endpoint in host.Description.Endpoints)
{
endpoint.Behaviors.Add(behavior);
}
host.Open();
Vous pouvez encapsuler et automatiser les étapes décrites dans La figure 3 en utilisant les méthodes d'extension, telles que les méthodes SetServiceBusPassword de ma classe statique ServiceBusHelper, présentée ici :
public static class ServiceBusHelper
{
public static void SetServiceBusPassword(this ServiceHost host, string password);
public static void SetServiceBusPassword(this ServiceHost host, string solution,string password);
}
Utilisant ces extensions, La figure 3 est réduite à la suivante :
ServiceHost host = new ServiceHost(typeof(MyService));
host.SetServiceBusPassword("MyPassword");
host.Open();
Vous pouvez voir une implémentation des méthodes SetServiceBusPassword sans gestion des erreurs dans l'exemple de code qui accompagne cet article.
ServiceBusHelper définit la méthode privée d'assistance SetBehavior, qui accepte une collection de points de terminaison et assigne un objet TransportClientEndpointBehavior fourni à tous les points de terminaison de la collection. Les méthodes d'assistance SetServiceBusPassword privées acceptent une collection de points de terminaison, le mot de passe solution et éventuellement le nom de la solution. Si le nom de la solution n'est pas spécifié, SetServiceBusPassword l'extrait de l'adresse du premier point de terminaison. SetServiceBusPassword crée un TransportClientEndpointBehavior, configure pour utiliser le mot de passe et appelle SetBehavior. Les méthodes publiques SetServiceBusPassword simplement appellent privées les avec la collection de points de terminaison de l'ordinateur hôte.
Le client doit suivre des étapes similaires, mais il y n'a qu'une seule extrémité à configurer, celui que le proxy utilise, comme illustré à la La figure 4 .
La figure 4 Définition du mot de passe solution sur le proxy
TransportClientEndpointBehavior behavior =
new TransportClientEndpointBehavior();
behavior.CredentialType = TransportClientCredentialType.UserNamePassword;
behavior.CredentialType = TransportClientCredentialType.UserNamePassword;
behavior.Credentials.UserName.UserName = "MySolution";
behavior.Credentials.UserName.Password = "MyPassword";
MyContractClient proxy = new MyContractClient();
proxy.Endpoint.Behaviors.Add(behavior);
proxy.MyMethod();
proxy.Close();
Là encore, vous devez encapsuler ce code répétitif des méthodes d'extension et prennent en charge similaire de manipuler les fabriques de classes. figure 4 à l'aide de ces extensions, est réduite à ce code :
MyContractClient proxy = new MyContractClient();
proxy.SetServiceBusPassword("MyPassword");
proxy.MyMethod();
proxy.Close();
la figure 5 illustre l'implémentation de deux le SetServiceBusPassword côté client <t> extensions. Remarque l'utilisation de méthodes d'assistance SetServiceBusPassword en encapsulant le seul point de terminaison le proxy a avec une collection de points de terminaison.
La figure 5 implémentation SetServiceBusPassword <t>
public static class ServiceBusHelper
{
public static void SetServiceBusPassword<T>(this ClientBase<T> proxy,
string password) where T : class
{
if(proxy.State == CommunicationState.Opened)
{
throw new InvalidOperationException("Proxy is already opened");
}
proxy.ChannelFactory.SetServiceBusPassword(password);
}
public static void SetServiceBusPassword<T>(this ChannelFactory<T> factory,
string password) where T : class
{
if(factory.State == CommunicationState.Opened)
{
throw new InvalidOperationException("Factory is already opened");
}
Collection<ServiceEndpoint> endpoints =
new Collection<ServiceEndpoint>();
endpoints.Add(factory.Endpoint);
SetServiceBusPassword(endpoints,password);
}
//More members
}
Étant donné que TransportClientEndpointBehavior est juste un autre comportement de point de terminaison, vous pouvez également le configurer dans le fichier de configuration. Stocker le mot de passe dans un fichier de configuration de texte, cependant, est fortement déconseillé.
Authentification par certificat
Utilisant un certificat pour s'authentifier sur le bus de service .NET est la meilleure option pour les applications non interactives, et vous pouvez définir le certificat par programmation et dans le fichier de configuration.
Le principal obstacle à l'aide de certificats est que le certificat doit contenir une clé privée, qui implique une séquence d'installation élaborés par l'administrateur de solution. Toutefois, une fois que la solution est configurée pour utiliser le certificat, le reste du travail est simple.
Le client et l'ordinateur hôte service utilisent tous deux entrées de configuration identique, comme indiqué dans La figure 6 .
La figure 6 solution certificat dans Configuration
<endpoint behaviorConfiguration = "RelayCert"
...
/>
...
<behaviors>
<endpointBehaviors>
<behavior name = "RelayCert">
<transportClientEndpointBehavior credentialType =
"X509Certificate">
<clientCredentials>
<clientCertificate
findValue = "MyRelayCert"
storeLocation = "LocalMachine"
storeName = "My"
x509FindType = "FindBySubjectName"
/>
</clientCredentials>
</transportClientEndpointBehavior>
</behavior>
</endpointBehaviors>
</behaviors>
Pour fournir par programme le certificat sur le côté ordinateur hôte, vous devez étapes similaire à ces illustré précédemment figure 3 . Outre la définition du type d'informations d'identification à TransportClientCredentialType.X509Certificate, vous devez utiliser la méthode SetCertificate de la propriété ClientCertificate sur Références. Ici, vous pouvez rationaliser l'aide de méthodes d'extension ordinateur hôte, comme illustré ici :
public static class ServiceBusHelper
{
public static void SetServiceBusCertificate(this ServiceHost host);
public static void SetServiceBusCertificate(this ServiceHost host, string subjectName);
public static void SetServiceBusCertificate(this ServiceHost host, object findValue,StoreLocation location,
StoreName storeName,X509FindType findType);
//More members
}
Par exemple :
ServiceHost host = new ServiceHost(typeof(MyService));
host.SetServiceBusCertificate("MyRelayCert");
host.Open();
SetServiceBusCertificate par défaut, la banque poste de travail et l'emplacement de mes, et il recherche le certificat par un nom. SetServiceBusCertificate également extrait le nom de la solution les points de terminaison ordinateur hôte.
Le client peut fournir également par programme le certificat à utiliser pour le proxy en suivant les étapes similaires à La figure 4 , et vous pouvez l'automatiser en utilisant ces méthodes d'extension, qui suivent les mêmes valeurs par défaut discutés pour l'ordinateur hôte :
public static class ServiceBusHelper
{
public static void SetServiceBusCertificate<T>(this ClientBase<T> proxy)
where T : class;
public static void SetServiceBusCertificate<T>(this ClientBase<T> proxy,
string subjectName) where T : class;
public static void SetServiceBusCertificate<T>(this ClientBase<T> proxy,
object findValue,StoreLocation location,StoreName
storeName,X509FindType findType) where T : class;
//Similar methods for a channel factory
}
Utilisant les extensions côté client génère ce code :
MyContractClient proxy = new MyContractClient();
proxy.SetServiceBusCertificate("MyRelayCert");
proxy.MyMethod();
proxy.Close();
Aucune authentification
Bien que le service doit toujours s'authentifier auprès du bus de service, vous pouvez décider exempter le client et autoriser le qu'accès au service relais non authentifié. Dans ce cas, le client doit la valeur TransportClientEndpointBehavior TransportClientCredentialType.Unauthenticated. Lorsque les clients non authentifiés par le service relais, il est désormais haut vers le service relayé pour authentifier les clients. L'inconvénient est que le service maintenant est moins protégé que lorsque le service de relais authentifié les clients. En outre, vous devez utiliser sécurité des messages pour transférer les informations d'identification client (comme indiqué plus loin). Pour activer l'accès non authentifié par le client, le service et le client doivent explicitement autoriser qu'il en configurant le relais liaison à n'authentifie pas, l'utilisation de l'enum RelayClientAuthenticationType, illustré ici :
public enum RelayClientAuthenticationType
{
RelayAccessToken, //Default
None
}
Vous affectez cet enum via la propriété de sécurité.
Sécurité de transfert
L'aspect crucial suivant de la sécurité consiste à transférer en toute sécurité le message via le relais au service. Parallèlement à la sécurité de transfert de message, une autre conception importante décision est le client les informations d'identification (le cas échéant) le message doit contenir. Sécurité de transfert est indépendante de comment le client ou le service authentifie lui-même sur le bus de services .NET.
Le groupe de services .NET propose quatre options de sécurité de transfert, représenté par l'énumération EndToEndSecurityMode :
public enum EndToEndSecurityMode
{
None,
Transport,
Message,
TransportWithMessageCredential //Mixed
}
Les quatre options sont Aucun, transport, un message et mixte. Aucun signifie simplement que, le message n'est pas du tout sécurisé. Transport utilise SSL ou HTTPS pour sécuriser le transfert des messages. Sécurité des messages crypte le corps du message afin qu'il peut être envoyé sur transports non sécurisés. Mixte utilise message sécurité contiennent des informations d'identification du client mais transfère le message via un transport sécurisé. la figure 7 illustre la façon dont la liaison de relais prend en charge les différents modes de sécurité transfert et leurs valeurs par défaut. Un signe plus gras (+) marque par défaut.
| Liaison de la figure 7 et sécurité de transfert |
| Liaison | Aucun | Transport | Message | Mixte |
| TCP (relayé) | + | + | + | + |
| TCP (direct/hybride) | + | - | + | - |
| WS | + | + | + | + |
| Unidirectionnel | + | + | + | - |
Vous pouvez configurer sécurité transfert dans la liaison. Bien que les liaisons de relais utilisent des valeurs par défaut différent, toutes les liaisons de relais offrent au moins un constructeur qui accepte EndToEndSecurityMode comme paramètre de construction. Vous pouvez également configurer sécurité transfert après la construction en accédant à la propriété de sécurité et sa propriété mode.
Sécurité du transport
Lorsqu'il s'agit de transférer la sécurité, sécurité du transport est la plus simple d'installer et configurer. Lorsque vous utilisez sécurité de transport, tous les appels clients sont anonymes, les messages client ne contiennent pas les informations d'identification client. Sécurité du transport est la plus simple à utiliser, il ne fournit pas sécurité bout à bout. Il sécurise uniquement le transfert du message au service de relais et du service de relais. Voyage dans le service de relais n'est pas sécurisé.
Cela signifie qu'en théorie, le service relais peut espionner les communications entre le client et le service et même falsifier les messages. Cependant, je pense que dans la pratique cela est peu pratique donné le volume du trafic du bus de services .NET. Pour simplifier, ce type de sous-version ne peut pas être exécuté dans un ailleurs et nécessite ressources dédiées, planification, le personnel et technologie. En outre, Microsoft s'est avéré au fil des années qu'a l'intégrité et respect de la confidentialité ses clients des plus élevé, et il est de nombreuses autres zones d'ont abusé s'il s'agissait en effet nuisible.
Sécurité des messages
Sécurité des messages crypte le corps du message en utilisant un certificat fourni par le service. Parce que le message lui-même est protégé plutôt que le transport, voyage dans le relais est ainsi protégé. L'inconvénient de sécurité des messages est qu'il nécessite étapes de configuration supplémentaires.
Alors que je pense que dans le transport pratique la sécurité est suffisamment, il est essentiel pour assurer aux clients et les utilisateurs de la présence de bout en bout pour confidentialité et l'intégrité et éviter les compromis même théoriques. Je recommande donc toujours compter sur la sécurité de message pour toutes les communications relayée, qui fournira également des avantages supplémentaires, tels que la connexion directe et la disponibilité du contexte de sécurité appel au service.
À la différence dans la sécurité de transport, de sécurité de message le message peut contenir les informations d'identification du client. La principale utilisation des informations d'identification client par le service est pour l'autorisation locale de l'appel à établir une stratégie de sécurité basée sur les rôles. Chaque fois que le message contient des informations d'identification, le service doit également authentifier les (même si tout ce qu'il veut est d'autoriser le client). Notez que cette authentification est en haut de l'authentification du service de relais a déjà effectué. Si le service de relais a déjà authentifié le client, authentifier à nouveau l'appel par le service n'ajoute pas de moyen de sécurité, mais il burdens le service de gestion des informations d'identification du client. Si le service relais s'authentifie pas le client, le service va être soumis à tout le trafic indésirable de clients non authentifiés, ce qui peut avoir des implications d'opérations informatiques graves.
Pour ces raisons, je trouve qu'il est recommandé pour le service relais pour authentifier le client et éviter que le service de recommencer. Vous devez également concevoir votre service afin qu'il n'ait aucun besoin des informations d'identification du client. Une telle conception est alignée sur le modèle de conception de la chaîne d'approbation fonctionne bien dans une architecture en couches. Ceci dit, il existe des cas lorsque le service doit les informations d'identification client pour une utilisation locale différente de l'autorisation, tels que personnalisation, l'audit ou propriétaire intégration avec les systèmes d'ancienne génération.
Liaison de relais TCP et sécurité de transfert
Le TCP relais par liaison défaut transport sécurité et sans étapes de configuration spéciales est nécessaires. Il utilise simplement SSL sur le port 828. Lorsque vous utilisez sécurité de transport, toutefois, vous pouvez utiliser uniquement le mode de connexion de liaison de relais TCP de TcpRelayConnectionMode.Relayed.
Étant donné que l'appel est anonyme, sur le côté service Windows Communication Foundation (WCF) joint une entité générique avec une identité vide à la thread exécutant l'appel et le ServiceSecurityContext est null.
Pour protéger le transfert du message, vous devez configurer l'ordinateur hôte service avec un certificat. Le client par défaut négociera le certificat (obtenir sa clé publique), il est inutile pour répertorier explicitement le certificat dans le fichier de configuration du client. Toutefois, le client doit toujours valider le certificat négocié. Comme avec WCF normal et sécurité des messages, la meilleure pratique consiste à valider le certificat utilise la confiance homologue, qui consiste à installer au préalable le certificat dans le dossier de personnes fiables du client. Outre la sécurisation du transfert de bout en bout pour true sur le relais, l'utilisation de sécurité des messages permet également l'utilisation des modes de connexion directe et hybride.
Comme indiqué précédemment, le message peut ou peut ne pas contienne les informations d'identification du client. Si vous évitez d'envoyer les informations d'identification dans le message, WCF s'attache à la thread exécutant l'appel un principal avec une identité vierge, n'a pas de sens beaucoup de Windows. Lorsque vous utilisez sécurité des messages sans informations d'identification, vous devez également définir ordinateur hôte PrincipalPermissionMode sur Aucun pour obtenir la même entité qu'avec la sécurité de transport. Pour configurer la liaison de sécurité des messages avec les appels anonymes, utilisez MessageCredentialType.None et affectez cette valeur à la propriété ClientCredentialType de MessageSecurityOverRelayConnection, disponible dans la propriété message de NetTcpRelaySecurity. figure 8 illustre code qui illustre cela.
La figure 8 configuration une liaison pour la sécurité des messages avec les appels anonymes
public sealed class NetTcpRelaySecurity
{
public EndToEndSecurityMode Mode
{get;set;}
public MessageSecurityOverRelayConnection Message
{get;}
//More members
}
public sealed class MessageSecurityOverRelayConnection
{
public MessageCredentialType ClientCredentialType
{get;set;}
//More members
}
La figure 9 montre le fichier config ordinateur hôte côté requis.
La figure 9 Configuration de l'exécution de la sécurité des messages
<service name = "..." behaviorConfiguration = "MessageSecurity">
<endpoint
...
binding = "netTcpRelayBinding"
bindingConfiguration = "MessageSecurity"
/>
</service>
...
<serviceBehaviors>
<behavior name = "MessageSecurity">
<serviceCredentials>
<serviceCertificate
findValue = "MyServiceCert"
storeLocation = "LocalMachine"
storeName = "My"
x509FindType = "FindBySubjectName"
/>
</serviceCredentials>
<serviceAuthorization principalPermissionMode ="None"/>
</behavior>
</serviceBehaviors>
<bindings>
<netTcpRelayBinding>
<binding name = "MessageSecurity">
<security mode = "Message">
<message clientCredentialType = "None"/>
</security>
</binding>
</netTcpRelayBinding>
</bindings>
Sur le côté client, vous devez inclure le nom du certificat de service dans l'identité adresse du point de terminaison car ce nom ne correspond pas au domaine de service de relais. figure 10 montre le fichier de configuration requis.
La figure 10 Configuration du client pour la sécurité de message
<client>
<endpoint behaviorConfiguration = "ServiceCertificate"
binding = "netTcpRelayBinding"
bindingConfiguration = "MessageSecurity"
<identity>
<dns value = "MyServiceCert"/>
</identity>
...
</endpoint>
</client>
<bindings>
<netTcpRelayBinding>
<binding name = "MessageSecurity">
<security mode = "Message">
<message clientCredentialType = "None"/>
</security>
</binding>
</netTcpRelayBinding>
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name = "ServiceCertificate">
<clientCredentials>
<serviceCertificate>
<authentication certificateValidationMode= "PeerTrust"/>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
Si vous souhaitez inclure les informations d'identification client dans le message, le service doit également authentifier les informations d'identification, en utilisant le même paramètre comme avec les appels TCP normaux. Dans ce cas, l'identité principale et principal du service s'attribuer une identité correspondant à ces informations d'identification. Les informations d'identification peuvent être un nom d'utilisateur et mot de passe, un certificat ou un jeton émis. Vous devez indiquer l'ordinateur hôte et le client dans la liaison qui types souhaité des informations d'identification. Par exemple, informations d'identification de nom de l'utilisateur, utilisez :
<bindings>
<netTcpRelayBinding>
<binding name = "MessageSecurity">
<security mode = "Message">
<message clientCredentialType = "UserName"/>
</security>
</binding>
</netTcpRelayBinding>
</bindings>
Sur le côté ordinateur hôte, si les informations d'identification du nom d'utilisateur et mot de passe, vous devez également configurer, l'aide de comportements, comment authentifier et autoriser les informations d'identification. La valeur par défaut sera informations d'identification Windows, mais le choix le plus courant serait utiliser certains banque d'informations d'identification comme les fournisseurs ASP.NET :
<service name = "..." behaviorConfiguration = "CustomCreds">
...
</service>
...
<serviceBehaviors>
<behavior name = "CustomCreds">
<serviceCredentials>
<userNameAuthentication
userNamePasswordValidationMode = "MembershipProvider"
/>
</serviceCredentials>
<serviceAuthorization principalPermissionMode = "UseAspNetRoles"/>
</behavior>
</serviceBehaviors>
Le client a remplir le proxy avec les informations d'identification. Lorsque vous utilisez un nom d'utilisateur et mot de passe, le code client serait Insérer comme suit :
MyContractClient proxy = new MyContractClient();
proxy.ClientCredentials.UserName.UserName = "MyUserName";
proxy.ClientCredentials.UserName.Password = "MyPassword";
proxy.MyMethod();
proxy.Close();
Le client n'a aucun moyen de savoir si les informations d'identification qu'il fournit sont authentifiées sur le côté service que Windows ou des informations d'identification personnalisées.
Sécurité mixte transfert est le seul moyen pour éviter les appels anonymes sur la sécurité du transport. Puisque la sécurité du transport ne peut pas passer des informations d'identification, vous transmettre les informations d'identification en utilisant la message sécurité, par conséquent, le terme mixte. Lorsque utilisant la sécurité mixte transfert sur le relais TCP liaison vous sont limités à l'aide de relayé seulement connexions.
La figure 11 montre comment configurer le service ou le client pour la sécurité mixte.
La figure 11 configuration pour la sécurité mixte
<endpoint
binding = "netTcpRelayBinding"
bindingConfiguration = "MixedSecurity"
...
/>
...
<bindings>
<netTcpRelayBinding>
<binding name = "MixedSecurity">
<security mode = "TransportWithMessageCredential"/>
</binding>
</netTcpRelayBinding>
</bindings>
Une fois les messages sont reçues par le service, l'ordinateur hôte doit authentifier les appels comme avec TCP normale. Une fois authentifié, l'appel de service possède un objet principal correspondant les informations d'identification fournies et un contexte d'appel de sécurité.
Liaison de relais Web et sécurité de transfert
Associant la liaison Web sécurité de transport revient à modification le schéma d'adresse à partir de HTTP en HTTPS et définissant la liaison à utiliser la sécurité de transport, comme dans La figure 12 .
Liaison de relais Web figure 12 avec sécurité de transport
<endpoint
address = "https://MySolution.servicebus.windows.net/..."
binding = "wsHttpRelayBinding"
bindingConfiguration = "TransportSecurity"
...
/>
<bindings>
<wsHttpRelayBinding>
<binding name = "TransportSecurity">
<security mode = "Transport"/>
</binding>
</wsHttpRelayBinding>
</bindings>
Notez que le Web de relais par défaut de liaison de l'aide de sécurité de transfert de message sécurité. Étant donné que sécurité des messages exige des étapes de configuration supplémentaires, le Web relais liaison ne fonctionne pas comme - est l'emploi, et tous les appels échouera. Cependant, configurer le relais Web liaison à utiliser message (ou mixte) sécurité est identique à la configuration la liaison de relais TCP.
Liaison de relais à sens unique et sécurité de transfert
La liaison de relais à sens unique (et ses sous-classes) sont la liaison uniquement n'avoir aucune sécurité transfert tout par défaut. En outre, il ne prend pas en charge sécurité mixte transfert. Configurer pour utiliser la sécurité de transport est le même qu'avec les liaisons de relais TCP et Web. Configurer pour utiliser la sécurité de message est similaire à une différence importante près, la liaison de relais à sens unique ne peut pas négocier le certificat du service car il y a pas encore peut-être un service et aucune interaction directe avec le service n'a lieu. Lorsque vous utilisez sécurité des messages sur le client, vous devez spécifier explicitement le certificat du service, comme illustré figure 13 .
La figure 13 unidirectionnel liaison de relais de sécurité des messages
<client>
<endpoint behaviorConfiguration = "ServiceCertificate"
...
</endpoint>
</client>
<behaviors>
<endpointBehaviors>
<behavior name = "ServiceCertificate">
<clientCredentials>
<serviceCertificate>
<scopedCertificates>
<add targetUri = "sb://MySolution.servicebus..."
findValue = "MyServiceCert"
storeLocation = "LocalMachine"
storeName = "My"
x509FindType = "FindBySubjectName"
/>
</scopedCertificates>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
Une autre distinction importante entre la liaison de relais à sens unique et les autres liaisons de relais est que si l'appel est anonyme, de sécurité de transport ou de message, l'appel a un contexte d'appel de sécurité dont l'identité principale est
service bus certificate CN=servicebus.windows.net.
Rationalisation de la sécurité de transfert
Tandis que le transfert de sécurité offre une série de détails et des options complexes, vous pouvez et devez simplifier et automatiser la plupart de ces décisions de configuration de sécurité. Pour encapsuler ordinateur hôte côté, utiliser ma classe ServiceBusHost, définie comme insérer les éléments suivants :
public class ServiceBusHost : ServiceHost
{
public ServiceBusHost(object singletonInstance, params Uri[] baseAddresses);
public ServiceBusHost(Type serviceType,params Uri[] baseAddresses);
public void ConfigureAnonymousMessageSecurity(string serviceCert);
public void ConfigureAnonymousMessageSecurity(string serviceCert,
StoreLocation location,StoreName storeName);
public void ConfigureAnonymousMessageSecurity(StoreLocation location,
StoreName storeName,X509FindType findType,object findValue);
//More members
}
Lorsque vous utilisez ServiceBusHost, aucun autre paramètre dans la configuration ou dans le code n'est requis. Par Ma recommandation, vous pouvez utiliser la méthode ConfigureAnonymousMessageSecurity pour activer les appels anonymes sur la sécurité des messages. Vous devez fournir est le nom certificat à utiliser :
ServiceBusHost host = new ServiceBusHost(typeof(MyService));
host.ConfigureAnonymousMessageSecurity("MyServiceCert");
host.Open();
ConfigureAnonymousMessageSecurity par défaut l'emplacement de certificat à l'ordinateur local et le magasin de certificats à mes, et il va rechercher le certificat par son nom commun. Si vous n'appelez pas ConfigureAnonymousMessageSecurity, ServiceBusHost par défaut à l'utilisation de sécurité des messages anonyme avec le nom de solution pour le nom de certificat :
ServiceBusHost host = new ServiceBusHost(typeof(MyService));
host.Open();
Vous pouvez également utiliser les versions surchargées qui permettent de spécifier explicitement certains ou tous les détails du certificat.
ServiceBusHost utilise le ConfigureBinding méthode de ServiceBusHelper. ConfigureBinding par défaut les appels anonymes. Si les appels doivent avoir des informations d'identification, ConfigureBinding utilise toujours les informations d'identification de nom d'utilisateur. Avec la liaison de relais TCP, ConfigureBinding utilise le mode de connexion hybride. ConfigureBinding permet également toujours fiables des messages.
ServiceBusHost prend également en charge la sécurité des messages avec des informations d'identification via les méthodes ConfigureMessageSecurity :
public class ServiceBusHost : ServiceHost
{
public void ConfigureMessageSecurity();
public void ConfigureMessageSecurity(string serviceCert);
public void ConfigureMessageSecurity(string serviceCert,
string applicationName);
public void ConfigureMessageSecurity(string serviceCert,
bool useProviders,
string applicationName);
//More members
}
ConfigureMessageSecurity par défaut, à l'aide les fournisseurs d'appartenance ASP.NET, mais il peut être invité à utiliser ainsi les comptes Windows. L'implémentation de ConfigureMessageSecurity est similaire à celle de ConfigureAnonymousMessageSecurity.
Vous pouvez fournir un moyen facile de configuration de sécurité des messages avec mon ServiceBusClientBase <t>, défini en tant que clients
public abstract class ServiceBusClientBase<T> : ClientBase<T> where T : class
{
public ServiceBusClientBase();
public ServiceBusClientBase(string endpointName);
public ServiceBusClientBase(Binding binding,
EndpointAddress remoteAddress);
public ServiceBusClientBase(string username,string password);
public ServiceBusClientBase(string endpointName,
string username,string password);
public ServiceBusClientBase(Binding binding,EndpointAddress address,
string username,string password);
protected virtual void ConfigureForServiceBus();
protected virtual void ConfigureForServiceBus(string username, string password);
}
ServiceBusClientBase <t> offre deux jeux de constructeurs. Les constructeurs qui prennent simplement les paramètres de point de terminaison par défaut tout l'utilisation de sécurité des messages avec les appels anonymes. Vous pouvez également utiliser les constructeurs qui acceptent les informations d'identification nom d'utilisateur et mot de passe. Est par défaut si aucune identité d'adresse de point de terminaison n'est fournie, ServiceBusClientBase <t> celui il solution. Vous utilisez ServiceBusClientBase <T> comme le ClientBase fournie par WCF <T> :
[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
class MyContractClient : ServiceBusClientBase<IMyContract>,IMyContract
{
public MyContractClient()
{}
public void MyMethod()
{
Channel.MyMethod();
}
}
Le téléchargement de code exemple inclut l'implémentation complète de ServiceBusClientBase <t>. ServiceBusClientBase <t> utilise confiance homologue pour valider le certificat du service. L'essentiel du travail est effectué en passant la liaison de point de terminaison à ServiceBusHelper.ConfigureBinding.
Le point d'inconvénients restant une est la liaison de relais à sens unique, avec son manque de négociation de certificat. Pour atténuer qui, j'ai écrit OneWayClientBase <t> :
public abstract class OneWayClientBase<T> : ServiceBusClientBase<T> where T : class
{
//Same constructors as ServiceBusClientBase<T>
public void SetServiceCertificate(string serviceCert);
public void SetServiceCertificate(string serviceCert,
StoreLocation location,
StoreName storeName);
public void SetServiceCertificate(object findValue,
StoreLocation location,StoreName storeName,X509FindType findType);
}
OneWayClientBase <T> dérive ServiceBusClientBase <T> et ajoute les méthodes SetServiceCertificate. Si vous appelez jamais SetServiceCertificate, OneWayClientBase <t> simplement recherche le certificat du service de configuration. SetServiceCertificate offre un moyen par programme simple d'éviter complètement la configuration. Il définit même la balise d'identité de l'adresse de point de terminaison. SetServiceCertificate utilise les mêmes valeurs par défaut comme ServiceBusHost, notamment le nom de solution pour le nom de certificat si aucun certificat n'est fourni. Voici comment vous utiliser OneWayClientBase <t> :
class MyContractClient : OneWayClientBase<IMyContract>,IMyContract
{
public MyContractClient()
{}
public void MyMethod()
{
Channel.MyMethod();
}
}
MyContractClient proxy = new MyContractClient();
proxy.SetServiceCertificate("MyServiceCert");
proxy.MyMethod();
proxy.Close();
Comme vous pouvez le voir, l'utilisation de OneWayClientBase <t> est simple.
Envoyez vos questions et commentaires à mmnet30@Microsoft.com.
Juval Lowy un logiciel architecte à IDesign, spécialiste des formations et du conseil en architecture WCF. Son dernier livre se Programming WCF Services 2nd Edition (o ' Reilly, 2008). Il est également directeur régional Microsoft pour la Silicon Valley. Contacter Juval à www.idesign. NET.