I have a c# .net wcf web service on a windows server with iis. I need to know if there is a way to tell the web service that it can accept request only from specific URL.
example:
ApplicationA call ApplicationAwebService = should work
ApplicationB call ApplicationAwebService = should be denied
Right now, they are all on the same server, but I need a solution that works even if they are on a different server (3tier applications).
thanks
If you are using WCF then its possible to use mutual authentication between services and clients. Mutual authentication achieves not only security for the server to accept connections from legit clients but provides the ability for the clients to verify that they are talking to a legit server.
Mutual authentication can be achieved through Message security (Encrypting the data sent between the client and server and vice versa) by using certificates, kerberos (Windows auth), tokens and a username/password configuration.
Mutual authentication can also be achieved in WCF through rolebased authentication, identities, and resource based authentication
Reference from msdn: https://msdn.microsoft.com/en-us/library/ff647503.aspx
Related
I am looking to host a WCF service accessible to a limited set of clients over the internet, as described here:
Best way to secure a WCF service on the internet with few clients
I intend to use Username/Password auth (using existing membership infrastructure) at this stage, with transport security (i.e. SSL).
I'm wondering what the recommended approach would be to processing the authentication request, when the membership database is obviously internal to the corporate network.
Options I'm considering are:
the public firewall would do SSL offload, and then the DMZ server would reverse proxy the request to the internal WCF server - I'm assuming credentials would be retained and passed through with this method, and the internal service could appropriately make use of the Membership provider to authenticate the user.
Write a dumb WCF service to sit externally which will make use of custom username/password authentication. This will call an Authentication Service internal to the network with access to membership details. Once the credentials are validated the call will then basically be passed through to the internal service that implements the required functionality.
Are both of these options possible? Are there any major pros/cons with either of them? (obviously reverse proxy is a lot less code...)
I have decided to use the second option. I already had a membership service internal to the firewall, so I will create the service to sit in the DMZ and implement a custom UsernamePasswordValidator and use it to call the membership service to validate credentials (and down the track I can then implement a custom ServiceAuthorizationManager to check roles/permissions).
Assuming credentials validate appropriately, the service will then call the main service internal to the firewall to carry out the functionality.
It's been a week already and I'm still not fully comfortable with implementing ASP.NET Membership Provider with WCF. I'm wondering:
We already have a website which is running under HTTPS protocol. We are working on a new application which will have a WCF service and is going to replace our old application (with HTTPS). Now my question is, since we already have a secured website, do I have to get another certificate just for the WCF service?
If yes, then do I have to get certificates for clients as well? (As I was looking on the web, most of the answers I found were "yes".)
If no, can I use the existing certificate to authenticate my service?
To answer your 2nd question, you only need client certificates if you want your WCF service to support mutual (2-way) SSL authentication, in which both the server and client sides are authenticated by their respective certificates.
Refer to this question for further information on mutual ssl and wcf.
how to implement 2-way SSL certificate for WCF
You have to have 1 SSL Certificate per domain unless you purchase a wildcard certificate. So, if your current SSL Certificate is for subdomain.mydomain.com and you want to host the WCF service at anothersubdomain.mydomain.com (or even www.anotherdomain.com), then you'll need another certificate. If this is something that would happen fairly frequently, then I'd suggest you purchase a *.mydomain.com SSL certificate.
Another option would be to host the WCF service under the current subdomain with a URL like subdomain.mydomain.com\myservice\service.svc.
I can't answer your second question but I doubt you are using client side certificates.
Here's a link to a Beginner's guide on SSL Certificates.
I'm planning on deploying a WCF service to multiple devices to receive notifications of certain events. All of the events will originate from a client machine that can provide a certificate to the service to authenticate.
I'm less concerned about the client authenticating each service, but I'm having difficulty choosing the proper WCF security settings to provide this setup. It appears that message-level security requires a client certificate and a service certificate.
But the devices hosting the service will not be able to be maintained in a way that allows us to update the service certificate periodically when it expires. So here are my questions:
Is there a way to set up a WCF service for client certificate authentication without a service certificate on the server?
Is there a simpler approach for verifying the identity of the caller that I'm missing?
I apologize for the brevity of this answer, but it is better to think of it as a Server certificate, rather than a Service certificate. Multiple services could use the same certificate, and you can work around the expiration by not checking for expiration client side. In terms of is there any easier way, WCF supports a variety of authentication and authorization models, here's some useful links.
http://msdn.microsoft.com/en-us/library/ee748498.aspx
http://msdn.microsoft.com/en-us/library/ms733131(v=vs.110).aspx
I'm currently developing a web api, with WCF web api, which allows me to write restful apis. One concern I have is security. For this reason I decided to protect my api with the OAuth protocol which works very good. However, the team got to the conclusion that our own applications shouldn't be authorized by oauth, instead they sould be authorized by http basic, meaning that the client application should send username and password.
So I have 2 questions:
How can I set up WCF Web Api to work with SSL, I'm using Web Api preview 6, and the project is a MVC3 application?
I have an operation handler which takes care of the creation of IPrincipal from the client access token, and then injects it into the operation parameters, so I can access the user's info. I would like to have in the same operation handler a condition where I could check if the authorization scheme is OAuth or http basic, and then in the case of http basic extract the user's credentials and authenticate that specific user against my data base, if authentication is successful create an IPrincipal and inject it to the operation parameters. However, as I see it, everytime an application using http basic requests something to the api, I would have to go to the data base and authenticate. So my question is: Am I in the right path, or this could be accomplished in some other way?
Any answers would be appreciate it. Thank you in advanced!
You setup SSL for WCF Web API just like you would any other WCF service exposed over HTTPS. If you are hosted in IIS, then you need to configure a site binding for HTTPS. If you are self hosted, then the configuration is bit more involved. See http://msdn.microsoft.com/en-us/library/ms733768.aspx for all of the details.
To handle basic auth against a custom identity provider you would typically use a custom authz module when hosted in IIS. See [http://custombasicauth.codeplex.com/] for an example of how to do this. If you are self hosted then you can use a custom username passworld validator. See http://msdn.microsoft.com/en-us/library/aa702565.aspx for details.
Yes, I believe you are correct that every request will require authentication unless you establish some sort of session-like semantics.
Hope this helps.
We have Windows Service with tcp binding. It has a transport security mode and client credential type is Windows. Service is within a domain.
Now we want to make calls to this service from the ASP.NET application running on IIS which is not part of the domain. We don't need user impersonation. What is the most secure way to enable this sort of communication?
This is a pretty standard situation: Web server is in DMZ and I would like to know how to set a secure communication with WCF backend services.
I expect that it will not work. You cannot use Windows client credential type if you want to consume the service outside of your domain. You must use Certificate (or None but it means no authentication).
The difference is that Windows client credentials will create stream secured with SSPI whereas Certificate and None client credentials will create stream secured with SSL certificate. In case of Certificate client credentials each client will be identified by its own certificate (= you need one for your IIS server).