Really simple (possibly stupid) question for the Azure experts out there.
I am currently in the process of building an application which uses web and worker roles and in the back end connects to WCF services. So in other words my web/worker roles call the WCF backend to obtain whatever data they need, currently they use certificate based authentication.
What I would like to understand is if WCF services hosted on Azure require security even if the endpoint will never be exposed publicly? Is there any reason to implement authentication on these private WCF services or is it safe to just set <security mode="None" />?
While your Worker or Web Roles are able to have private endpoints that are available to other instances within the same Hosted Service, please keep in mind that those private endpoints are NOT load-balanced.
You can check out this article to see how you can go around this issue: http://msdn.microsoft.com/en-us/magazine/hh148149.aspx
If you want load-balanced WCF endpoints, they need to be publically accessible through Azure's load balancer and thus you may want to (but do not have to) put security on top
Microsoft has been promising private load-balanced endpoints but nothing has come out yet.
HTH
Related
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
I have a public desktop site, a public mobile site, and a private intranet site on the same server. They are all written in C# (ASP.Net 4.0).
Each has their own code to process credit card payments. I would like to write a single application that handles credit card payments for all 3 sites. I want this application to only be accessible from these 3 local applications.
The only way I know how to do this is to create a web service and restrict traffic to the localhost.
Is there a better ("right") way to do this? Should I create a windows service instead?
The general approach is sound. However, I would not only rely on access being restricted to localhost. A single misconfiguration at some later point in time would expose your payment web service. Also, if the server is compromised, any process running on that local host would have unchecked access.
Always use authentication to secure your payment web service.
If you must deploy the authentication service on the same physical box as the front end websites, take particular care securing the payment service (e.g. if you are storing credit card numbers or PII related to the credit accounts e.g. name, address, ... ensure the database is correctly secured). If at all possible, place payment services in an additional layer separate from the public-facing (or co-worker facing) websites, protected by appropriate firewall rules.
I don't think windows service would be good option if you have calling applications. As far as I know about WCF, we have option for NetTcpBinding and NetNamedPipeBinding which you might consider.
NetTcpBinding - A secure and optimized binding suitable for cross-machine communication between WCF applications.
NetNamedPipeBinding - A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.
We have a WCF service running in Azure and have client application (WPF) consuming the servcie. Can anybody point me in the right direction on how I can secure the WCF service so that only my client application can access the public methods or applications allowed can access the public methods
there are lots of possibilities depending on binding you are using, an approach could be to use Message Security with X509 certification in WSHtttpBinding
you can read about it's example here
Disable Mex (Api information)
Use HTTPS to prevent man in middle attacks
these are general ideas based on your environment and constraints it can be different.
i'd like to recieve comments on the way i'm trying to build an asp.net web application which uses a WCF service that is hosted in another asp.net application. Both applications will live on the same machine, but the app with the WCF service will not be accessible from the outside. there will be two web servers sharing the load behind a load balancer.
The app pool of both applications will use the same local user account (web server is not part of a domain) and so i was thinking to use WsHttpBinding with windows security for communication between client and internal wcf service.
The fron-end asp.net app uses forms authentication through a custom membership/role provider to athenticate and authorize users. The user database is in a sql server database.
i need to somehow pass to the wcf service the user details (username + roles) so that in the wcf it will be possible to validate and authorize according to the roles of who is logged in the front-end. I read i need to use "support tokens", but i haven't figured out how to use this.
I read also something about claims and WIF, which seems interesting but have no idea how i could use these in my scenario.
is there anyone who can give me recommendations about the architecture and maybe also show me how to pass the username to the wcf service and also show me if possible to use claims based authorization?
First of all, if both servers are behind the corporate firewall on a corporate LAN, I would strongly suggest using netTcpBinding instead of any http based binding. NetTcpBinding is much faster due to encoding the message in a binary format.
As for username / password: your ASP.NET front-end server could set the client credentials for the user calling for the WCF service - after all, the ASP.NET servers do have access to the ASP.NET membership database, don't they?
Or if you cannot pass on the user's credentials, you could pass on some headers to your WCF service that would describe the user - actually, you probably only ever need the user's unique ID - since the WCF service could fish out the rest of the info from the ASP.NET user database again, if really needed.
As for claims - I don't think they'd be a good idea here - you don't really have to deal with a multitude of different authorization schemes, and you're not using any federation (e.g. allowing users from a different company or domain to use your services) - so those obvious benefits probably won't really be applicable to your case.
Is there a way I can configure my asp.net web service to work with only some applications? In other words, I am saying "only these applications have access to this web service and can therefore use it. Others can't".
When other applications tries to discover the service, it shouldn't even show up, or at least it should conceal it web methods.
PS: I am wondering if this scenario is even applicable to the whole concept/domain of web services? Plus, I am asp.net 2.0 oriented, but you can give me answers based on higher framework versions, but be specific...Thanx in advance.
I'd look at WCF (after all ASMX web services are now regarded as legacy)- there is a whole load of options regarding security configuration. Patterns and Practises have Security Guidance here. It sounds like you are most interested in authorization, so read about Access Control Mechanisms.
Also to make the service non discoverable in WCF you just don't expose a MEX endpoint. That doesn't stop clients connecting, but makes it hard for people to work out how to call the service. That said you can also secure the MEX endpoints so that is another option.
Can you put some authorization or login method to initialize usage of webservice?
We control usage of services by explicitly logging into the webservice or provide some authorization token.