I have an existing WCF service, written in C#, which is hosted in an own process (not in IIS). Now I want to re-configure this service, so that the following requirements are met:
It has to use basicHttpBinding
It has to use SSL
No code changes, just changes in the service's and client's .exe.config file
Username and password authentication; as there is only one known client, a single hard-coded username/password would be sufficient
I have already searched pretty much but it seems that 4. and 3. are not possible in this combination. The ideal thing would be if one could just hard-code a username and password in the service's .exe.config file. Is this possible at all?
If yes, how would such a config file look like?
If no, what would be feasible alternatives, meeting requirements 1.-3. and what would their config file look like?
To get 1 through 3 try the following (Really no code changes just configuration and setup):
SSL with Self-hosted WCF Service
However 4, I think, will be impossible without code changes you will need to provide that user name/password to the service somehow and then on the service do a check for it. Configuration wont save you there, need to roll up your sleeves and put down some C# .NET!
Related
I have a WCF self-hosted as a Windows Service.
When I start the service (under the NETWORK_SERVICE account), I can consume the service from my ASP.NET application on a different server.
However, the business rules have changed. Now I need to run the service under my own account. I am able to stop the service, and start it again under my account. No problem there.
Until I try to consume the service from my ASP.NET application on the other service. I get:
A call to SSPI failed, see inner exception
I'm relatively certain there's something I need to do security wise to eliminate this error, being new to all this I just don't know what.
Any help is greatly appreciated.
Thanks,
Jason
Usually this is a sign of a missing or misconfigured SPN, which gets in the way when you're using windows authentication (at the transport or message level) and Kerberos is being negotiated.
Notice that how/when the error manifests itself might depend on the way the hostname (or IP address) of the service host is used in the URL used by the client, since WCF will try, by default, to deduce the right SPN to use based on the URL information, unless you explicitly override it by setting the endpoint identity.
So likely all you need to do is register an SPN (using setspn.exe) for your new service and make sure your client uses an appropriate identity.
There's some more extra information on how WCF uses service identities here, here and here.
I'm using a WCF service with the NetNamedPipesBinding to communicate between two AppDomains in my process.
How do I secure the service so that it is not accessible to other users on the same machine?
I have already taken the precaution of using a GUID in the Endpoint Address, so there's a little security through obscurity, but I'm looking for a way of locking the service down using ACL or something similar.
See http://blogs.charteris.com/blogs/chrisdi/archive/2008/06/23/exploring-the-wcf-named-pipe-binding-part-3.aspx for one way to do it via ACLs.
you can use WCF authentication. One of the options is to validate against the windows username and password. If you use active directory, you can use that too (harder to set up, put less of a burden). http://blogs.msdn.com/pedram/archive/2007/10/05/wcf-authentication-custom-username-and-password-validator.aspx.
WCF NetNamedPipesBinding has only Transport Security
http://msdn.microsoft.com/en-us/library/ms731699.aspx
Is this a shared PC? Do you have several users logging on locally to the same physical machine?
For the sake of argument, lets say that I've got a basicHttp WCF service. Besides implementing authentication (login/logout methods), what is stopping someone from just cracking open Visual Studio, adding a web reference to my website's service, and then playing playing around with my service? I'm not familiar with a method of stopping someone from doing this. The idea of someone downloading all of my Data/Operation contracts and then start playing around is keeping me up at night, and I like my sleep!
Discoverability is the driving factor behind Web Services and especially SOAs. The ability of anyone at all who can reach the service to pull up the WSDL, generate a proxy in Visual Studio (or some other tool), and start using the service is one of the main reasons to create a web service!
I suppose you could generate all the client proxies and then disable the mex endpoint, but that pretty much cripples WCF, and even then it's only security through obscurity.
If you don't want any miscreant to start hitting your web service then either don't use the basicHttpBinding (which is designed for the express purpose of immediate and anonymous consumption) or host the service on a private network which only trusted clients can reach.
Some form of authentication or encryption is the only thing that can prevent this. You have to distinguish between those you want give access to, and those you don't. Give the ones you want to have access the certificate necessary to do encryption, or the username and password.
Don't give anything to the others.
We would like to keep the WCF in the configuration file.
At the same time we would like the code to refuse a request if the data will be sent over the net unencrypted. Something like: if the request is basichttpbinding without https, throw exception.
Is there any way for the service code to know how it is being called?
EDIT
From the comments it looks like the question was not that clear.
What I am trying to do is "fix" the following situtaion: We install a service with basichttpBinding and https. Then a administrator changes it to not use https. The effect is that data is sent unencrypted over the net.
I'm not sure I understand what you want... are you talking about validating, on the service itself, how it is being called and reject some requests if they don't meet certain criteria?
I'm sure that can probably be done (at least certain things, like checking for SSL are more or less simple), but first I'd ask why, if you only want your service called over secure bindings, why you're exposing the service using unsecured ones in the first place. Doesn't it make more sense to ensure the service configuration is correct?
Are you self-hosting?? The most simplistic approach would be:
ServiceHost serviceHost = new ServiceHost(typeof(Service1), "http://localhost:1234/MyService/xml");
foreach (ServiceEndpoint sep in serviceHost.Description.Endpoints)
{
if(sep.Binding.Scheme != "https")
{
// either just remove that endpoint, or signal an error
}
}
Of course, when you host in IIS, this gets a bit trickier... you might have to create your own custom ServiceHost descendant to do this check, and make sure your IIS based *.svc files use that custom host. Of course, a smart admin might be able to trick that by using the base ServiceHost instead of your own custom host class......
I don't have an example for you, but keep in mind that anything you can do through configuration with WCF, you can do in code. You don't even need to have a configuration file.
Caution, WCF noobie alert
I need to create a WCF client to query a non-WCF web service.
The web service is not a WCF service. Additionally, the web service requires a client authentication certificate. Now, I have the certificate, and can create a non-WCF client that works perfectly; I was able to 'Add Web Reference' and a certificate dialog box opened up to allow me to select the appropriate certificate, then went on to create the web reference. Trying to create a WCF client via 'Add Service Reference' is another story, it just fails with a 403 Access Denied error.
I have the WSDL for the service, and have run svcutil.exe on it, but am not sure how to proceed from there.
Thanks for any help!
I'm assuming that the service you are using is performing client SSL authentication.
Since add service reference is failing, you can use svcutil to generate the client from the WSDL file that you have. I think the syntax would be something like:
svcutil *.wsdl /l:C# /out:Reference.cs /config /s /ct:System.Collections.Generic.List`1 /ser:Auto /tcv:Version35 /n:*,<NameOfYourNamespaceHere> /edb
This will generate a file, Reference.cs, that contains the proxy classes to the service (you can give this file whatever name you want). Add this file to your project. A config file, output.config, will also be generated. You can add this configuration to your application configuration instead of typing it all in by hand.
Now you can follow this MSDN article on using Transport Security with Certificate Authentication. You can skip down to the client section where it shows how to attach the certificate to the request in code as well as in configuration.
I know this is the old question and it has been already solved but I would like to mention that Add service reference also works for WSDL files stored on disk. Marc has also mentioned it. Add service reference dialog accepts:
URL to WSDL
URL to Metadata exchange endpoint
Service URL where /mex is added internally
Any file path to WSDL file
So if you have WSDL and all need XSD files you can use Add service reference as well. The only tricky part is that Add service reference dialog doesn't have Browse button and that is the reason why this functionality is not well known.
Stupid question (maybe): could you connect to the service endpoint, present it with your credentials stored in the certificate, and then download the WSDL (and possibly XSD) from there? Or could it be the entity offering this service would be able to actually send you these files (or make them available for download)?
Once you have the WSDL (and XSD) file on disk, it should be easy enough to create WCF client for that (using either svcutil.exe or Add Service Reference) based on those files, and then configure the appropriate security for it.
Just a thought.... (worth $0.02?)
Marc
OK, bit of a work-around here (and I've no idea what is going on technically): I noticed that when you add a Web Reference, the certificate you have chosen is cached and automatically used the next time you add the Web Reference (I noticed because I'd chosen the wrong certificate). This caching seems to work across Web Reference and Service Reference so:
Add a Web Reference to the endpoint, choosing the certificate you wish to use
Remove this Web Reference
Add a Service Reference to the same endpoint and Visual Studio will use the same certificate you chose for the Web Reference
Worked on Visual Studio Community 2019, v16.7.7