I'm working on a Project where I run a Server that is basically a .Net C# Application with a SQL Server Express DB and will now use WCF for Webservice implementation and then there are Silverlight Clients that different Companies will use to interact with this Server. How do I implement User Authentication in a good and reliable way? I've read a lot of Posts here that will user ASP on the Server side, but my Server isn't an ASP Server. Should I implement it anyway or are there any other options?
My naive thought was something like that:
Username, Password and Company is stored as a credential in the DB
The Silverlight Client asks on Startup those credentials and sends them to the Server to get a confirmation.
from now on those credentials are in every communication between Client and Server and the Server confirms them every time.
Is this to naive and insecure?
Since you're using basic web protocol, you could consider using an HTTPS channel and
1) embedding the credentials in the URL - as long as you're using HTTPS this is OK
2) getting a unique identifier back from the service on initial validation of credentials, and then requiring this identifier in all future calls - saves on the db lookup, but you should still stay in https - if you use http, then it's by definition insecure
Related
For some reasons we must implement a custom auth method for a Net Framework 4.8 WCF service. It can be a custom basic or custom anything (for example token based) auth. The main goal is to publish a WCF service to IIS, but the clients need to use authentication (not anonymus) to access the service functions. During this authentication cannot use local users or AD users usernames and passwords. A virtual (fake) username + password pair should be the best.
Best solution would be not do develop anything, but an existing IIS authentication module is used (and configured). Unfortunately, our IIS server is still v6.2, and I cannot find any built-in auth modules to be configurable to authenticate the incoming request with an externally given static username + password pair. Like as an Apache .htpasswd file. Is there any?
I found examples on MS doc https://learn.microsoft.com/en-us/iis/develop/runtime-extensibility/developing-a-module-using-net but it seems developed for ASP.NET, not for WCF. Cannot find example for WCF services. Can anyone suggest a working example (server side, client side) for this? Hopefully only on server side a development must be, because if this is a fully working basic auth, on client side the specific (fake) username + password must be stored and used during the calls.
context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
Thanks for advance!
We have self-hosted C# WCF service providing rest API over HTTPS.
Problem:Configuring the certificates for SSL requires admin rights. I assume it is to do with WCF depends on http.sys for http/https handling. The service is meant to be deployed on customer environments. So it would be nice if it can run without requiring admin rights.
Looks like WCF depends on http.sys,
Can I self-host an HTTPS service in WCF without the certificate store and without using netsh http add sslcert?
Like to know if any other embedded web server solution exist that support SSL and not requiring admin rights on the machine?
Checked so far,
http://nancyfx.org/
https://github.com/pvginkel/NHttp
Both doesn't seem to support SSL.
Most windows hosted web stacks rely on the HTTP Server API which is the API around the kernel HTTP stack (a.k.a HTTP.sys). The .Net HttpListener class does so as well (same as WCF, the OWIN self hosted asp.Net and so on which rely on it).
Just making sure, you do know you can authorize the identity you application runs under to bind to an HTTPS URL even if it's not running as an admin account, right? If you could gain admin right just for the installation phase that could solve you problem? (assuming you checked that already)
You can read more on a blog post i wrote about that here
To go into the effort of building an http stack on top of raw sockets would be a great effort and with little gain and so around .Net i doublt you would find anything like that.
Unless, it wished to be cross platform.
Any java based web server would probably do just that, using the JVM's http stack and relying on a java keystore to provide the required certificates for the SSL. (To keep it portable across different OS's)
If you wanna go java i am sure you can find many such web servers.
If you care to try and bind to a web server using CGI have a look at mongoose (Never used it to be honest).
Another option which comes to mind is to use an ssl proxy like Stunnel to stand in front of the web server. It would do the SSL part using non-windows certificate store.
I will try to explain it as shortly as I can.
We use 'proxy' for the connection.
The web service that I can try to connect is Oracle Weblogic.I have got the username and the password.
I can connect to the web service without any problem by using the progrqm soapUI.And on the program I choose this option.Becaue I can only connect to the web service by choosing this.
Authenticate Preemptively : Send Authentication headers with each request without first receiving an authentication challenge. This is a potential security hazard but will improve performance since only one request will be required for authenticated endpoints instead of two.
I can not connect to the web service by using C# winform.I made a lot of research but I could not find anything helpful.
Could you give me an example?
Please have a look at the sample here in connecting to a web service via C#. Or you can use a code first method. which ever suites your needs.
Happy Coding :)
It's running into an Intranet, .net framework 3.5, hosted in IIS 7.0 and it's using wsHttpBinding with null security. Now I have to protect it to allow only specific users can run it.
Seems that I should use SSL and certificates but I'd really like stay away of that because looks complex, basically I'm looking for the simplest way.
I took a look to netTcpBinding and seems to me this is the right way, if so, can you confirm if using net.tcp it would be able to be consumed by some asp.net site.
Any comments are welcome.
Thanks,
In your case you have an intranet, which means that you have internal users. It depends where the call to the WCF service is coming from.
If we assume:
Internal users, who login to a windows domain
The client machines and the server are in the same domain
The user runs a windows app on their machine, which makes the WCF call
Then the simplest solution is to use windows authentication
The client makes the call in the security context of the logged on user
The server checks the group membership of the user to determin if it should allow access
You said you are using an Intranet app.
If so, you could turn on Windows Authentication, and allow only specific users in IIS (this is also controlled in the web.config). If everyone is on the intranet, it should authenticate automatically without users needing to enter a password or user name.
However, if anyone outside your intranet needs to reach this service, you'll need to include SSL & https to protect the credentials sent to the service.
I want to write a web service using Visual Studio. The service needs to support some type of authentication, and should be able to receive commands via simple HTTP GET requests. The input would only be a method call with some parameters, and the responses will be simple status/error codes. My instinct would be to go with an ASP.NET Web Service, but this isn't an option in C# 4.0 and it makes me wonder if I should be using something that's more up-to-date. I've looked into WCF, but it seems like this requires a running application on the client-side - is there a way to query a WCF host by just accessing a URL?
The authentication is also an important piece. Developing my own little authentication system seems like a bad idea - I've read that it's too easy to mess up. What would be the standard way of authenticating with a web service like this?
I'd love to look up all of the specifics on this and learn it myself, but I really don't even know where to begin. Some direction would be greatly appreciated!
For a simple HTTP service that takes commands via GET (you should actually consider using POST...) I would use straight ASP MVC, not a true
'web service'. WCF wants to guide you down the path of SOAP and your clients will curse you forever. RESTful WCF is also an alternative, but it still seem overkill imho.
As for authentication, you have two viable authentication schemes:
Windows Integrated security, which will work only if client is inside intranet or connected with a VPN or DirectAccess solution
HTTP Digest, which is poorly supported by the ASP authentication modes (only support authenticating against a Active Directory forest user base).
With Windows authentication you don't do anything on the server side code, simply mark the the web.config <authentication mode="Windows" />. 'Windows' authentication is understood by most user agents. Is trivial to program clients of your service to use Windows authentication too, simple set the request's Credentials to the current user DefaultCredentials.
With Digest authentication the server will challenge the user agent to authenticate, but the ASP validation unfortunately, as I said, only works for validating a trusted NT domain. The client though does not need to be in the intranet (there is no NTLM SSPI exchange between client and server). Programming a client is faily easy, in .Net simply set the requet Credentials to a properly initialized CredentialsCache:
CredentialCache myCache = new CredentialCache();
myCache.Add(new Uri("http://www.contoso.com/"),"Digest", new NetworkCredential(UserName,SecurelyStoredPassword,Domain));
...
request.PreAuthenticate = true;
request.Credentials = myCache;
It is important to reuse the cache between requests, otherwise the client will do two round-trips with each call.
In theory you can also have a third authentication path: full duplex SSL. But the 'trivial' problem of client certificate deployment makes this alternative a dead end for anybody short of a fully pre-installed enterprise PKI.