locked
Custom authorize and JSON body content question RRS feed

  • Question

  • User982889344 posted

    Here is my web service ......

    [Route("GetTodaysTimecard")]

    [HttpPost]
    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 ?

    Wednesday, December 21, 2016 12:44 PM

All replies

  • User-2057865890 posted

    Hi StephenH,

    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.

    reference: https://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api

    Best Regards,

    Chris

    Thursday, December 22, 2016 7:23 AM
  • User753101303 posted

    Hi,

    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 anyway?

    Thursday, December 22, 2016 8:43 AM
  • User982889344 posted

    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?

    Thursday, December 22, 2016 10:31 AM
  • User982889344 posted

    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.

    Thursday, December 22, 2016 10:35 AM
  • User753101303 posted

    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.

    Thursday, December 22, 2016 11:58 AM
  • User982889344 posted

    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......

    Thursday, December 22, 2016 12:10 PM
  • User753101303 posted

    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).

    Thursday, December 22, 2016 12:40 PM
  • User982889344 posted

    Again.. my original post asks this ....

    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?

    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 .......

    Thursday, December 22, 2016 12:47 PM
  • User753101303 posted

    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).

    Thursday, December 22, 2016 1:05 PM