Last post Dec 22, 2016 01:05 PM by PatriceSc
Dec 21, 2016 12:44 PM|StephenH|LINK
Here is my web service ......
public HttpResponseMessage GetTodaysTimecard(DeviceInfo deviceInfo)
DeviceInfo is a class so I can add and remove properties and not worry about parsing on the URL or any of that...this works fine but I am not sure what problems it may create now or in the future...can you guys elaborate on why this may not be a good idea?
I would like to use an authorize attribute but as I understand it when the authorize is called before the parameters have been bound so I cannot access the JSON payload in the authorize request method?????
Am I understanding this correctly?
Do I have options ?
Dec 22, 2016 07:23 AM|Chris Zhao|LINK
Web API provides a built-in authorization filter, AuthorizeAttribute. This filter checks whether the user is authenticated. If not, it returns HTTP status code 401 (Unauthorized), without invoking the action.
Dec 22, 2016 08:43 AM|PatriceSc|LINK
Or explain your scenario. On one side it seems you want to restrict your web service call to authorized user but you still want to get the incoming data if the user is not authorized ??? What's the point of reading those data if the user is not authorized
Dec 22, 2016 10:31 AM|StephenH|LINK
Hey Chris, I have looked into that but it seems that I cannot use the JSON payload in the body as part of the AuthorizationAttribute filtering logic right?
Dec 22, 2016 10:35 AM|StephenH|LINK
I want to use data in the JSON body payload as the authorization.....
I am communicating over HTTPS and I can send in a token or a hash in the body with data and not have to have all kinds of excessive or extraneous authorization schemes.
You could simply include something like the IMEI of the device (mobile or IOT) and check it against your authorized device list in the database and be done.
Dec 22, 2016 11:58 AM|PatriceSc|LINK
Rather than doing this check in the controller, you would rather create your own custom authorization attribute: see for example http://www.infoworld.com/article/2988903/application-architecture/how-to-secure-web-api-using-authorization-filters.html
I would perhaps post this as a http header (to avoid having to include a partiuclar value in possibly unrelated json payloads). This is for mobile client I guess...
Edit: note though that it means you switched from user authentication to device "authentication". Make sure it's does bring a benefit without introducing some unwanted behavior.
Dec 22, 2016 12:10 PM|StephenH|LINK
First, thanks for the response....
I use it for mobile and other things .. IMEI can be a serial number of any kind...or a hash .. or a GUID....
The part that contains the serial number or IMEI or whatever is already part of every JSON payload I receive.
I have read that article ......
In the article the are sending in parameters like this: [Authorize(Users="Joydip,Jini")] //Restrict access by user
In my opinion it's unrealistic to pass something like this into a web service .. you end up with endless configuration possibilities and membership collisions and maintenance.....if I have the serial number of a device or a key then all I do is update
the database and we are good.....
I will look at adding the information to the header but that just seems to be even more work than simply including the identifier for every payload in the payload itself....
We are sending the user in the JSON payload as well for validation so we validate the user and device are BOTH authorized to talk to us....
It's 2016 (just about 2017) and I fully expected that things like this would be much simpler to implement......
Dec 22, 2016 12:40 PM|PatriceSc|LINK
Ok I badly choosed this one ;-) The point is that you can create custom authorization attributes and you have full control on what they are doing.
I've done some more research and if I had to implement this I would likely start with https://www.asp.net/web-api/overview/security/authentication-filters
Generally speaking you don't have to do things such as adding authorization code directly in your controller code. .NET Framework have extensibility points already used by bult-in mechanism and you can take advantage of them as well.
So in this particular case you would end up in writing your own authentication attribute to then just apply it wherever you want (or maybe globally).
Dec 22, 2016 12:47 PM|StephenH|LINK
Again.. my original post asks this ....
I cannot seem to find anything that uses the JSON payload in my body of the request in the authorization code.... it appears that you do do not have access to the body payload in the authentication filter .......
Dec 22, 2016 01:05 PM|PatriceSc|LINK
If you tried which error do you have? To me it seems it should be possible through the
HttpAuthenticationContext that exposes the Request and its content. You would then have to deserialize the expected json payload to check for that value (similar to what i used using HttpClient, hopefully you'll just include the needed values and
all the other stuff that might be included in the payload would be ignored as well).
This is why I would rather use a http header. It seems easier to test and it allows to better separate the authentication information from other actual json stuff you may need.
I would likely need to test my own code to go beyond that (but can't right now).