any insights are helpful
A good explanation can be found on the .NET Development Forum:
[I]t is not true that you have to
enable anonymous in order to host WCF
in IIS. There are some restrictions
when you configure bindings though.
The basic principle is that: the
settings for the WCF binding should be
compatible with IIS settings. This
means that if you want to enable
transport layer authentication in the
binding, you have to do so to the
virtual application in IIS. For
example, when you use
BasicHttpBinding, you can enable the
transport layer auth by setting the
security Mode to
"TransportCredentialOnly". You can
disable IIS anonymous auth in this
case.
However, there is one special case: if
you are using WSHttpBinding over HTTP
instead of HTTPS, you would have to
enable anonymous in IIS. This is
because none of the security modes for
WSHttpBinding allows you to configure
transport-layer authentication over
HTTP, which has been implemented in
BasicHttpBinding. Of course, you can
solve this by using either
BasicHttpBinding or CustomBinding.
This is not a limitation. Instead it
tries to reduce confusion since you
would use either SSL (as transport
layer security) or message security
with WSHttpBinding.
Related
I'm new to WCF and have very limited knowledge in WCF security. I have written an WCF service which should be exposed in internet for my clients. I need to Authenticate the clients to use my services. Clients should invoke my service with user id and password. I will do SSL certification as well but apart form that I need some authentication mechanism. Please advice me what binding,security mode, clientCredentialType and related configurations I should do for the security.
You can make use of WSHttpBinding for your services. The binding supports HTTPS transport and WS-Security. Along with this, you can also set security configuration at transport and message level. You can either specify that at ServiceContract or at OperationContract levels.
Here are few MSDN links to get you started:
Bindings and Security
WCF Security Fundamentals
Authentication with Transport Security
Please note that these may be very basic in comparison to your requirements.
It depends on what technology your clients use. If they are all .NET then you have free choice. If you have Java or other clients accessing your services you may have less headaches with BasicHttpBinding, which is completely adequate if you only need username authentication and SSL. The link #danish provided (http://msdn.microsoft.com/en-us/library/ff649647.aspx) shows you how to do that.
I would like to authenticate user trying to use my SS web services. I found the sample code and followed PLURALSIGHT tutorial but I was wondering if user/password used during first connection is encrypted or something on the network?
At this time we used to secure our WCF with certificates but THAT'S A REAL PAIN! and at the same time passing user/password on each WS is a security failure.
How does SS manage security of authentications parameters? Can I use it like that without worrying about possible security failure?
Credentials will be sent plain text and it is expected that you configure SSL for the authentication traffic.
ServiceStack is just a standard ASP.NET or HttpListener web application. The standard way to encrypt HTTP traffic in any Web Application is to call your services over https. HTTPS is enabled/configured outside of your ServiceStack service (i.e. Web Application layer) so ServiceStack itself doesn't require any special attention when enabling SSL.
Setting up HTTPS on ServiceStack is the same as any other IIS/ASP.NET or HttpListener application. In both cases HTTPS is a transport layer security (TLS) protocol that is enabled at the WebServer/Host level (e.g. IIS) and not in your web application (e.g. ServiceStack). So when seeking how to enable SSL you should be looking on how to enable it at the WebServer host level, e.g. IIS, Nginx, HttpListener, etc (and not ServiceStack).
E.g. If you've got ServiceStack hosted in an ASP.NET Host, than a simple search for IIS SSL on Google will provide plenty of instructions and walk throughs like this one. If you've got ServiceStack hosted in a self-hosted HTTP Listener, see this answer instead.
If your service is being consumed in an Enterprise environment and if you have AD, you can consider using WSHttpSecurity binding with binding configuration set to use Windows Credentials. This can eliminate the use of certificate. If your service is cross-enterprise and you dont have AD, you will have to do certificates
If you are doing Windows credential type, here's a sample config
<security mode="Transport">
<message clientCredentialType="Windows" />
</security>
Here on MSDN as well as here states the when dealing with wsHttpBinding, Transport security is handled via SSL.
On the MSDN page about SSL and WCF it states that when a ServiceHost is hosted within IIS, the ServiceHost leaves the SSL to be handled by IIS.
Would this not imply that if binding/securityMode="Transport", that any wsHttpBinding/binding/security/transport/clientCredentialType values would be ignored as none of their options are needed to set up the SSL transport?
It even appears to to say something to this effect here when it states
"When setting the security mode to TransportWithMessageCredential, the
transport determines the actual mechanism that provides the
transport-level security. For example, the HTTP protocol uses Secure
Sockets Layer (SSL) over HTTP (HTTPS). Therefore, setting the
ClientCredentialType property of any transport security object (such
as HttpTransportSecurity) is ignored. In other words, you can only set
the ClientCredentialType of the message security object (for the
WSHttpBinding binding, the NonDualMessageSecurityOverHttp object)."
And yet here for basicHttpBinding and for wsHttpBinding, they both categorically emphasis with examples that if security mode is set to Transport, set the binding/transport/clientCredentialType to something (eg: Windows).
What's the exact difference between Transport and TransportWithMessageCredential?
And do I have the wrong end of the stick, and the SecurityType enum (None|Message|Transport|Mixed) is not just for privacy, but for authentication to the server?
If Transport security is provided by SSL encryption, how did Authentication/Authorization get tangled into this stage?
Thanks immensely for helping me get a better picture of how this all fits together.
As far as I know the TransportWithMessageCredential is kind of "best of both worlds". The channel is secured on the transport layer so there is a secure connection between client and service (which can be very fast, implemented in hardware), plus the message is signed with message credentials so it can survive multiple hops before arriving at the service (validated in WCF).
And of course, you can use message credentials which are not supported on the transport layer, username/password for example.
Is it possible to configure a WCF service that:
is hosted by IIS
uses the basicHttpBinding binding
does not need an SSL cert
supports sessions (ServiceContract(SessionMode:=ServiceModel.SessionMode.Required))
I know the easiest thing to do would be to buy an SSL cert, but for reasons beyond my control I am being required to match the 4 constraints above.
thanks,
Tom
Tell your boss that basicHttpBinding supports real security only when using with SSL certificate (otherwise all data are passed as a plain text) and it doesn't support WCF sessions out of the box. WCF session is dependent on either:
Transport session (only netTcp or netNamedPipe bindings)
Reliable session (only netTcp, wsHttp or custom bindings)
Security session (only wsHttp or custom bindings and it requires either windows authentication or SSL certificate)
Sessions can be probably added by building your own service behavior and replacing IInstaceContextProvider and perhaps also IInstanceProvider.
In one of our networks we are utilizing the netTCPBinding. The WCF service hosted in windows service that run as a domain account.
From the event viewer I can see that my WCF service uses Kerberos authentication. Everything works seamlessly "out-of-the-box" with simple default configuration without an <identity> element in the configuration file and without any SPN setting for the machine like:
setspn -a WcfServiceName//Server domaonAccount
But from the multiple online references I concluded that SPN setting is necessary
Its not clear, why in my case it works without those settings?
Looking forward for an explanation from WCF-Security experts.
Per the WCF Security Guidance:
netTcpBinding : Specifies a secure, reliable, optimized binding suitable for
cross-machine communication. By default, it generates a runtime
communication stack with transport security and
Windows authentication as default security settings. It uses
TCP protocol for message delivery, and binary message
encoding.
In essence, its secure by default, callers must provide Windows creds for authentication.