I need to lock down a wcf service with basic authentication and SSL. However it is on shared hosting who won't enable it for me. Is there a way of mimicing basic authentication in code with just code that would likely work in a shared environment? I want SharePoint Online to read this wcf service and apparently it presents credentials as basic.
You probably will not be able to get this done with your shared hosting service. SSL requires a registered domain name to associate with the keys. Your hosting service should offer a dedicated site with SSL, shop around for the best price.
Related
I have a .NET web application, authentication is typically done through windows authentication. Normally it's placed on a local lan and is a member of a domain so users authenticate directly to AD. However I was told that I had to figure out to authenticate to the domain when the web server is on a perimeter network. I was told that adfs is the way to go. However I'm unsure of how to implement this. I read about the web application proxys but those would have the application on the lan. A relying trust sounds like what I want but it's not clear on technet how this works and how to integrate with anything other than a sharepoint site. I was told not to use something like a rodc because they don't want to extend the domain any further, which makes sense. Any suggestions on how to authenticate to active directory through adfs with the application being on the perimeter
There is a free and well known e-book on federated authentication from the Patterns & Practices group, Claims based identity and access control
https://msdn.microsoft.com/en-us/library/ff423674.aspx
The book covers all you need to set up federated applications, write federated clients and servers and much more. When you are done with reading, come back with more specific questions.
I am being driven slowly and inexorably mad by the setup of IIS to allow access to Exchange Web Services from ASP.NET website that uses Windows Authentication. I have found literally dozens of articles on how to set this up, each of which seems to say something different, or else describes a process to me that fails when I duplicate it, presumably by there being some assumed knowledge on my part.
Application uses windows authentication to identify the user.
Application sends emails using EWS such that the email ends up in the users "sent items"
Exchange is hosted on a separate server than the web server, so I am assuming the "double-hop" I have read about issue is occurring. I am not a sysadmin, so I do not really understand this.
Is there some clear way for me to setup this up to work, and then potentially troubleshoot the problem?
Yes, from your description it certainly looks like a double-hop problem. It's non-trivial to fix, basically you need to setup delegation between the web server and the exchange server to for the web server to be able to use the kerberos ticket issued when the user logs in to the web server.
I have yet to deploy a single solution that actually does that. We have always ended up either using a service account (with appropriate access rights to exchange, mailboxes etc.) or place the web application on the exchange server. Neither option is particularly elegant, but in most cases operations teams have been unwilling to set up delegation or known how to do it properly.
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.
Scenario
I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.
The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.
I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.
Questions
With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?
A few suggestions to consider:
List the threats, and compare each to your current setup.
Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords
The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.
That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.
There are a few simple options:
SSL + Cookie
If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).
Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.
I have a Web Service (ASMX) with a few Web methods on our production Web server. On a separate internal Web server (which isn't publicly exposed) I have another Web site that will use the ASMX's public web methods. What are some of the best ways to secure the Web service such that only the internal Web server can access the Web Services running on the publicly exposed Web server?
One of the easiest ways is to pass credentials in the soap header of the message. So each call passes along the info needed to determine if the user is authorized. WSE makes some of that easier but one of the most succinct descriptions of this process can be found in Rocky Lhotka's book on Business Objects. I get a lot of books to review by publishers and this one had the best explanation
Assuming you don't have the option of using WCF, I'd advocate using WSE 3 (Web Service Enhancements). You can get the toolkit / SDK thingummy at MS's site
To limit the access to only internal machines (as I think your question asked), I'd set up a separate web site in IIS and set it to only respond to the internal IP address of your server.
I would set a firewall rule to restrict access to a whitelist of IP addresses.
Use IIS's directory security IP address restrictions, and limit access to just that internal web server IP address.
If you can't do that then, and you can't setup a username/password on the directory, then use WSE and add a username/password into the service, or look at certificates if you want some fun grin
Maybe I did not understand correctly, but why expose the web methods publicly at all if they're only going to be consumed by the internal server?
A simple HTTP module will work. Just hardcode (or from config) the allowed IP/host and reject all others.
If it is only the internal server that will be accessing the asmx files? You could set them up in IIS under a separate web site or virtual directory, then place some IP restrictions on the site. In properties, go under Directory Security, then "IP Address and Domain Name Restrictions."
Also, for passwords, WSE 3 is the new go-to, but I did find a simple method in a book from Apress called "Pro ASP.NET 2.0 in C# 2005" Chapter 34. (Note, the newer version of this book omits this chapter.) The section is custom Ticket-based authentication.
In this moment what comes to my mind is IP filtering on IIS. Fast to apply, should work in your scenario.
TLS with client certs. See Wikipedia entry to get started.
Be aware that there are ways around whitelisting IPs. Don't get me wrong, it's a great idea, and you should definetly do it, but if your budget/resources allow it, you can expand your threat model.