I am a newbie who is writting ASP.Net web API service for the very first time. The issue I am having is how to pass user information or different contexts via service request. For example I want to pass user context (i.e username, user preferences etc.) and lets say security context (i.e. api key, secret etc.) thru each service call. The options I found
1. using Query string
2. custom HTTP headers
3. overload authorization header to pass Jason object
4. cookie
I ditch the idea of using query string as it has 2k limitation, custom header could be ripped by proxy services, dont want to use cookie,creating a jason object of all the context and send it via auth header can work but seems like not a smart way. Any idea? what is the best way of passing those extra information.
I really appreciate if someone help me with some examples.
Related
I recently succeeded in building a page that loads data via an ajax get call to a REST interface (that runs on my server) and then uses the data to construct a map overlay for Google maps via JS.
I managed to do this but now I have concerns about the security of my data. Obviously everybody could just use curl to load the overlay data from my REST interface. However, I do not want to make my data so easily available, since they are kind of the business value of my page...
Is saw many solutions on the web that all require a login of the user.
However, this should not be required on my page.
Is there an easy solution to this problem, without the user having to use a log in or something? Basically I only want to allow my web application to query data from my REST interface, but not anyone else.
One solution that came to my head is to pass the data directly from php into JS, when the page is loaded. However this looks like a real ugly solution to me...
On a RESTful interface, I suppose you want to avoid login into a session. You have basically 2 more ways :
use IP address filtering if the web application run on a private network with known IP addresses
pass an identification token in the request headers or as a request parameter. The token has to be passed along in all the requests.
I am developing an enterprise app where I need to pass a Session ID in REST requests which will pass the same id in my EJB methods.
The approach I have taken is:
Create a Session ID whenever user logins. Use this session id to pass as Header Param in each api except login. (I am still figuring out how to exclude one REST API)
Use this session id in the Header and pass it to each EJB. (How to read header param in subsequent Rest calls after interceptor is invoked.)
Can anyone please let me know, if this is the right way to go?
Also, will generating a one-way hash for creating a session token useful rather than sending a auto-generated primary key?
Passing a token as a header parameter to identify a logged in user is a common approach. Actually using OAuth is basically the same idea, but adding a standard way of doing so and adding the possibility of expiring/revoking tokens.
About generating a one-way hash, yes. That's the way to go. An auto generated primary key would be a terrible idea. If I log in and I am assigned session 1427, I can be almost 100% sure that there is a 1426 session available for a different user right now. Huge security hole.
Make sure you make those tokens as hard to guess as possible and use https throughout the whole process or you will be exposing your login tokens to eavesdroppers.
Yes. Dont use autogenerated primary key. If you are using multiple layers of application and dont want to use JSESSIONID, use SecureRandom to generate a session-token and use it.
What options are available for authentication of an MVC3 Web API application that is to be consumed by a JQuery app from another domain?
Here are the constraints/things I've tried so far:-
I don't want to use OAuth; for private apps with limited user bases I cannot expect end users to have their accounts on an existing provider and there is no scope to implement my own
I've had a fully functioning HMAC-SHA256 implemention working just fine using data passed in headers; but this doesn't work in IE because CORS in IE8/9 is broken and doesn't allow you to send headers
I require cross-domain as the consuming app is on a different domain to the API, but can't use jsonp becuase it doesn't allow you to use headers
I'd like to avoid a token (only) based approach, as this is open to replay and violates REST by being stateful
At this point I'm resigned to a HMAC-SHA256 approach that uses either the URL or querystring/post to supply the hash and other variables.
Putting these variables in the URL just seems dirty, and putting them in the querystring/post is a pain.
I was succesfully using the JQuery $.ajaxSetup beforeSend option to generate the hash and attach it to the headers, but as I mentioned you can't use headers with IE8/9.
Now I've had to resort to $.ajaxPrefilter because I can't change the ajax data in beforeSend, and can't just extend data in $.ajaxSetup because I need to dynamically calculate values for the hash based on the type of ajax query.
$.ajaxPrefilter is also an issue because there is no clean/simple way to add the required variables in such a way that is method agnostic... i.e. it has to be querystring for GET and formdata for POST
I must be missing something because I just cannot find a solution that:-
a) supports cross-domain
a) not a massive hack on both the MVC and JQuery sides
c) actually secure
d) works with IE8/9
There has to be someone out there doing this properly...
EDIT
To clarify, the authentication mechanism on the API side is fine... no matter which way I validate the request I generate a GenericPrincipal and use that in the API (the merits of this are for another post, but it does allow me to use the standard authorization mechanisms in MVC, which I prefer to rolling my own... less for other developers on my API to learn and maintain)
The problem lies primarly in the transfer of authentication information from the client to the API:-
- It can't rely on server/API state. So I can't pass username/password in one call, get a token back and then keep using that token (open to replay attack)
- Anything that requires use of request headers is out, because IE uses XDR instead of XHR like the rest of the browsers, and it doesn't support custom headers (I know IE10 supports XHR, but realistically I need IE8+ support)
- I think I'm stuck generating a HMAC and passing it in the URL somewhere (path or querystring) but this seems like a hack because I'm using parts of the request not designed for this
- If I use the path there is a lot of messy parsing because at a minimum I have to pass a username, timestamp and hash with each request; these need to be delimited somehow and I have little control over delimiters being used in the rest of the url
- If I use data (querystring/formdata) I need to change the place I'm sending my authentication details depending on the method I'm using (formdata for POST/PUT/etc and querystring for GET), and I'm also polution the application layer data space with these vars
As bad as it is, the querystring/formdata seems the best option; however now I have to work out how to capture these on each request. I can use a MessageHandler or Filter, but neither provide a convienient way to access the formdata.
I know I could just write all the parsing and handling stuff myself (and it looks like I will) but the point is I can't believe that there isn't a solution to this already. It's like I have (1) support for IE, (2) secure and (3) clean code, and I can only pick two.
Your requirements seem a little bit unjustified to me. You can't ever have everything at the same time, you have to be willing to give something up. A couple of remarks:
OAuth seems to be what you want here, at least with some modifications. You can use Azure's Access Control Service so that you don't have to implement your own token provider. That way, you have "outsourced" the implementation of a secure token provider. Last I checked Azure ACS was still free. There is a lot of clutter when you look for ACS documentation because people mostly use it to plug into another provider like Facebook or Google, but you can tweak it to just be a token provider for your own services.
You seem to worry a lot about replay attacks. Replay attacks almost always are a possibility. I have to just listen to the data passing the wire and send it to your server, even over SSL. Replay attacks are something you need to deal with regardless. Typically what I do is to track a cache of coming requests and add the hash signature to my cache. If I see another request with the same hash within 5 minutes, I ignore it. For this to work, I add the timestamp (millisecond granularity) of the request and some derivative of the URL as my hash parameters. This allows one operation per millisecond to the same address from the same client without the request being marked as replay attack.
You mentioned jQuery which puzzles me a bit if you are using the hashing method. That would mean you actually have your hash algorithm and your signature logic on the client. That's a serious flaw because by just inspecting javascript, I can now know exactly how to sign a request and send it to your server.
Simply said; there is not much special in ASP.NET WebAPI when it comes to authentication.
What I can say is that if you are hosting it inside ASP.NET you'll get support by ASP.NET for the authentication and authorization. In case you have chosen for self-hosting, you will have the option to enable WCF Binding Security options.
When you host your WebAPI in ASP.NET, you will have several authentication options:
Basic Authentication
Forms Authentication - e.g. from any ASP.Net project you can enable Authentication_JSON_AppService.axd in order to the forms authentication
Windows Authentication - HttpClient/WebHttpRequest/WebClient
Or explicitly allow anonymous access to a method of your WebAPI
I have a scenario where I am trying to combine spring security with jersey for my REST API.
My need is rather complicated (I think) and it is as follows:
Spring security is being used to intercept urls and forcing basic authentication in order to access a REST resource. This seems to be ok as I am using http client to test this.
However what I want to do is somehow access the User object that is loaded to check some additional permissions that hang off the user (a map object with boolean flags to indicate if object properties are visible or not). The code that does the loading works, but after spring authenticates how do I then access the User object in the actual REST Resource method itself?? Is this possible?
So the steps are:
1) Client makes a REST API call
2) Spring intercepts URL checks username and password supplied in the http header
3) The rest resource method is then accessed if valid credentials are present
But before step 3, I want to somehow pass on the loaded User object to the actual Resource method itself so I can further apply some logic to restrict what the user can see based on the permissions that I have loaded??? Is this possible? I think I have seen some code somewhere that checks for User Roles before a method is accessed using Spring and REST but if anyone has any links or ideas that would be excellent.
Please help if you can. thank you so much.
I solved this by using a request-scoped proxy which was constructed by a bean factory.
This allows you to simply inject your currently authenticated user into any spring managed bean, and in my case my Jersey Resources fell into that category. I injected my user into the tier below the resources, but it's all the same.
Someone else elegantly blogged the full solution here.
I need to get a list of tasks for a user from a WCF service to display on an iPhone app. I'm planning to use something like http://www.nayyeri.net/custom-username-and-password-authentication-in-wcf-3-5 to authenticate, but how would I pick up the username/user ID to filter my list of items?
You'll need to follow the example in the answer to this question on custom validator access to the user name. This good overview of custom service credentials shows how all the pieces work together. On the iPhone side, you'll need to configure the client to perform Basic HTTP authentication over HTTPS to successfully call the service.