views:

406

answers:

1

I'm having a hard time getting my head around this, and Google just isn't being helpful.

I'm looking at converting some legacy code to use the following technologies: ASP.NET, WCF, jQuery.

The ASP.NET conversion isn't an issue, nor is accessing the WCF service for data, on the server-side.

However, what I'm having an issue with is potentially being able to secure the service so that I can return JSON-formatted data, requested via jQuery on the client-side, but lock it down to prevent external access.

For this particular implementation, it's not that big of a deal, since the ... quasi-Ajax-like functionality has been in place for quite a while, and there hasn't been abuse.

But, once this project is complete, I'd like to take what I've learned and convert another form, which is often abused, and allow for a slicker display.

If I want to do client-side calls to a Web service, am I stuck making my Web service open to anonymous access?

Short of securing the Web interface down to a specific subset of users (I see no issue with securing the added functionality to logged in users), are there any other strategies on securing a Web service in this scenario? Am I just overlooking something obvious?

A: 

Require an authenticated session for both the server-side page and its caller via ajax, with both behind HTTPS.

Another strategy is to use a token that is bound to the session during the last page load to confirm that the session itself has not been high-jacked. This is done when the client loads the page. The server tracks what the next token must be to confirm a valid request.

Jeff Ober
Re Token: I was actually thinking about that earlier on, then pushed it onto the back burner. However, I don't recall why any longer ...That would also allow for a deal of flexibility; either let the tokens expire x minutes after they were assigned, or allow a semi-rolling expiration (up to a certain amount of time).
James Skemp