{"id":31212,"date":"2021-01-07T09:00:30","date_gmt":"2021-01-07T16:00:30","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=31212"},"modified":"2021-01-05T15:29:50","modified_gmt":"2021-01-05T22:29:50","slug":"wsfederationhttpbinding-in-net-standard-wcf","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/wsfederationhttpbinding-in-net-standard-wcf\/","title":{"rendered":"WSFederationHttpBinding in .NET Standard"},"content":{"rendered":"

As .NET Core has evolved, the WCF team has worked to expand support for WCF client scenarios on .NET Standard and .NET Core. Until recently, one of the gaps developers faced when building WCF clients for .NET Core was the lack of WSFederationHttpBinding<\/code> and WS2007FederationHttpBinding<\/code>. These bindings support WS-Federation authentication scenarios where users authenticate with a security token service (like Active Directory Federation Services) and use a token from that authentication provider to authenticate with a separate service (called the ‘relying party’). Last month, the System.ServiceModel.Federation package<\/a> (targeting .NET Standard 2.0) released, enabling these client WCF scenarios!<\/p>\n

This post covers the basics of getting started with System.ServiceModel.Federation in your .NET Core application. It goes over how to install the package and how its use differs from previous WS-Fed WCF scenarios.<\/p>\n

Using WSFederationHttpBinding<\/code><\/h2>\n

To use the .NET Standard-compatible version of WSFederationHttpBinding<\/code>, add a reference to the System.ServiceModel.Federation<\/code><\/a> package with version 4.8.0<\/code>.<\/p>\n

<PackageReference Include=\"System.ServiceModel.Federation\" Version=\"4.8.0\" \/>\r\n<\/code><\/pre>\n
This package contains the WSFederationHttpBinding<\/code> type that is now used for both WSFederationHttp and WS2007FederationHttp scenarios. A key difference between .NET Framework WCF scenarios and .NET Core WCF scenarios is that .NET Core doesn’t use application config files for setting up WCF objects, so the binding will need to be configured in code rather than in app.config<\/code>, as you might have previously done for .NET Framework.<\/p>\n
If you’re using a WCF client (derived from ClientBase<T><\/code>) to interact with your WCF service, you can use the client’s constructor that takes a Binding<\/code> and an EndpointAddress<\/code> as parameters. In many cases, existing client code generated by .NET Framework’s SvcUtil will continue to work. Just make sure you’re using client constructors that accept a binding as a parameter instead of one that expects to create the binding from configuration. Updates to dotnet-svcutil<\/a> and Visual Studio’s WCF Web Service Reference Provider Tool<\/a> are planned which will enable auto-generating .NET Standard-specific clients for WCF services with WS-Federation bindings.<\/p>\n
The WSFederationHttpBinding<\/code> constructor takes a single parameter of type WSTrustTokenParameters<\/code>. This parameter is used to specify details about the token issuer (STS) the binding should get tokens from and how those tokens should be handled. The easiest way to create an instance of WSTrustTokenParameters<\/code> is to use the WSTrustTokenParameters.CreateWS2007FederationTokenParameters<\/code> or WSTrustTokenParameters.CreateWSFederationTokenParameters<\/code> helper methods. These static methods will create WSTrustTokenParameters<\/code> for WS2007Federation and WSFederation scenarios, respectively. Both methods take the issuer binding (also called the ‘inner binding’) and endpoint address as parameters. It’s also possible to create your own WSTrustTokenParameters<\/code> via the constructor and specify exactly the behavior you need. Important properties on the WSTrustTokenParameters<\/code> type include:<\/p>\n