J'ai une exigence pour sécuriser un point de terminaison de service WCF net.tcp en streaming à l'aide de WIF . Il doit authentifier les appels entrants sur notre serveur de jetons. Le service est diffusé car il est conçu pour transférer de grandes quantités de données.
Cela semble impossible. Et si je ne peux pas contourner le piège, mon Noël sera ruiné et je me boirai à mort dans une gouttière pendant que de joyeux acheteurs enjambent mon corps qui se refroidit lentement. Totes sérieux, vous les gars.
Pourquoi est-ce impossible? Voici le Catch-22.
Sur le client, je dois créer un canal avec le GenericXmlSecurityToken que j'obtiens de notre serveur de jetons. Pas de problème.
// people around here hate the Framework Design Guidelines.
var token = Authentication.Current._Token;
var service = base.ChannelFactory.CreateChannelWithIssuedToken(token);
return service.Derp();
Ai-je dit "pas de problème"? Problemo. En fait, le NullReferenceException
style problemo.
"Bro," ai-je demandé au Framework, "est-ce que vous êtes même nul?" Le cadre était silencieux, j'ai donc démonté et trouvé que
((IChannel)(object)tChannel).
GetProperty<ChannelParameterCollection>().
Add(federatedClientCredentialsParameter);
était la source de l'exception, et que l' GetProperty
appel revenait null
. Alors, WTF? Il s'avère que si j'active la sécurité des messages et que je règle le type d'informations d'identification du client sur, IssuedToken
cette propriété existe maintenant dans le ClientFactory
(protip: il n'y a pas d'équivalent "SetProperty" dans IChannel, le bâtard).
<binding name="OMGWTFLOL22" transferMode="Streamed" >
<security mode="Message">
<message clientCredentialType="IssuedToken"/>
</security>
</binding>
Sucré. Plus de NRE. Cependant, maintenant mon client est blâmé à la naissance (l'aime toujours, tho). En creusant dans les diagnostics WCF (protip: faites faire cela à vos pires ennemis après les avoir écrasés et les avoir conduits avant vous mais juste avant de profiter des lamentations de leurs femmes et enfants), je vois que c'est à cause d'un décalage de sécurité entre le serveur et le client.
La mise à niveau demandée n'est pas prise en charge par «net.tcp: // localhost: 49627 / MyService». Cela peut être dû à des liaisons incompatibles (par exemple, la sécurité est activée sur le client et non sur le serveur).
En vérifiant les diags de l'hôte (encore une fois: écraser, conduire, lire les journaux, profiter des lamentations), je vois que c'est vrai
Le type de protocole application / ssl-tls a été envoyé à un service qui ne prend pas en charge ce type de mise à niveau.
"Eh bien, moi-même," dis-je, "je vais simplement activer la sécurité des messages sur l'hôte!" Et je fais. Si vous voulez savoir à quoi il ressemble, c'est une copie exacte de la configuration du client. Chercher.
Résultat: Kaboom.
La liaison ('NetTcpBinding', ' http://tempuri.org/ ') prend en charge le streaming qui ne peut pas être configuré avec la sécurité au niveau des messages. Pensez à choisir un mode de transfert différent ou à choisir le niveau de sécurité du transport.
Ainsi, mon hôte ne peut pas être à la fois diffusé et sécurisé via des jetons . Catch-22.
tl; dr: Comment puis-je sécuriser un point de terminaison WCF net.tcp en streaming en utilisant WIF ???
<security mode="Transport" /> <transport clientCredentialType="IssuedToken" /> </security>