I am trying to use Dropwizard as a full web server, combining serving public pages, protected pages and data through REST API. So, I am validating the ability to protect some routes by applying a custom authorization scheme based on a computed token and a realm to manage different security areas.
I have difficulties to understand how to achieve the purpose. The sequence I was expecting is the following :
display an HTML login page with a user form
user enters its credentials
call an authenticate route to validate credentials and create a token for the user. Send back a welcome page with an Authorization header like : MyScheme token="TYGDF655HD88D098D0970CUCHD987D897", realm="SUPER SECRET STUFF"
user click a link to list its invoice : /html/invoices
this route is protected by DropWizard #Auth annotation
no header is sent by the browser so the server answer with a 401 response with a header : WWW-Authenticate MyScheme realm="SUPER SECRET STUFF", challenging the browser to give it an authorization header matching the challenge
Unfortunatly, the browser didn't send it this header. According to many articles, I thought browser managed authorization cache for all received credentials, their scheme and parameters (such as realm).
It seems browser have this behavior for well known schemes such as Basic authentication, but not for custom scheme (by the way, it's usually an issue for basic auth since browser can't "logout" a user since he does not erase the web history or close the browser).
How do you think it's possible to tell a browser to cache authorization credentials and to add them each time a server request is challenging it with the right scheme / realm ?
I could display here all the example codes I use to make this example run.
A reference (good to read) : RFC1945 at https://www.rfc-editor.org/rfc/rfc1945#section-11
Thank you for your help.
Running dropWizard 0.9.2 on Jdk Oracle 1.8 / Debian 8.
Browser doesn't manage authorization. It never does, or at least never should.
Server should always keep its cache, and verify input from the browser.
At a basic level, all of the fields you need, are part of the HTTP Header. If you inject the request, you'll have access to them.
If dropwizard doesn't have things you need, you can always ignore everything, and simply read the request headers and do the custom processing you need.
For instance, add a Filter which sets the realm, something like WWW-Authenticate: Basic realm="myrealm:"
Authorization: MyScheme Ceasar-cipher-password. You'll need to parse it and process it yourself, perhaps set up an incoming Filter on all requests, or selective requests.
Is it a good idea, I'll let you be the judge. Perhaps, in your use case it makes sense.
If you have a look at the source code and how the BasicCredentials are used, perhaps, it can provide insight in a potential solution you may adapt yourself.
Hope it helps.
Related
I have a basic html, which contains a form. This form submission is handled by a RESTful backend api service (written in spring boot). The html page is unprotected for business reasons -any sort of authentication / login mechanism can't be applied on the HTML. How can I make sure, only the html is allowed to hit the backend APIs, and not other sources? Both the html and backend apis are under the same domain. Example - example.com/index.html; example.com/getStudentList
How can I make sure, only the html is allowed to hit the backend APIs, and not other sources?
If I'm understanding things correctly, you don't want consumers of your API to authenticate with the API, because reasons? But what you want is that any client that loads the index page can access the API.
The closest implementation I can think of that would work at all like that would be to treat the API urls like a one time pad: You dynamically generate the html page, with urls that include some difficult to guess token. When the API receives any request, it checks the token -- if there is no token, it rejects the request (403 - Forbidden). If there is a token, it checks whether or not that token is still active; if the token is expired, then the request is rejected. If the token is inactive, but within some grace period, you might redirect the API request to a URL with a newer token (301 - Moved Permanently). If the token is active, then you serve the request.
Mark Seemann, while trying to solve a different problem, wrote a nice little introduction: Avoiding Hackable URLs.
If that sounds to you like a session cookie -- well, you aren't far wrong. To be completely honest, I suspect that the differences are subtle, and I wouldn't be surprised to discover that I exaggerate them. The primary differences are that we are communicating things like cache invalidation and the resource lifecycle explicitly to intermediary components. The Cookie header, on the other hand, is effectively opaque.
This answer is certainly imperfect -- anybody who happens to guess the currently active URL is going to be able to access the API whether they hit the index page or not. Obscurity, rather than security.
But it might be enough to tide you over until you have reasonable requirements.
I have implemented an authorized action as explained in this question as well as the answer by #vdebergue.
This was working great, and the requests made by the front-end application were automatically adding an X-XSRF-TOKEN request header, with the token obtained from the login response.
However upon deploying both front-end and back-end, the requests issued from the browser are no longer adding the X-XSRF-TOKEN request header, thus causing an Unauthorized response from the server (rightfully so).
What I am failing to understand is, what is it that changed between development and deployment?
I do have the request header specified in cors.allowedHttpHeaders:
play.filters.cors.allowedHttpHeaders = ["Accept", "Origin", "Content-Type", "X-XSRF-TOKEN"]
I doubt I have to add this header manually from React (in fact the issue probably has nothing to do with the front-end).
Thanks!
Edit 1:
List of XHR requests:
Details of the login POST request, can see the X-XSRF cookie and the token being passed:
Details of the unauthorized GET that is not setting the X-XSRF as request header:
Same as previous screenshot, but running on localhost, getting authorized with the header added:
Assuming you implemented correctly, and the cookie is not attached during deployment, the issue might be related to the domain of your cookie. The way I did it is to define an an env variable and use it to hold the domain value; so it does not break the implementation during development and tests.
You can look at the Playframework API documentation for more information on how to use the cookie.
Solved in an unconventional matter: front end was made with react, which offers a way to build a static production version.
I simply integrated those static files with play framework's index.scala.html, instead of trying to run it as a separate app on a different port.
It works, however i will not mark it as a best answer yet, because i don't know whether a mobile app connecting to the same play framework backend will play along nicely when it comes to authorisation and cookies. Mobile apps are not browsers (and maybe don't abide by their limitations), and Postman had no issues with cookies.
To be checked.
I'm creating a headless API that's going to drive an Angular front end. I'm having a bit of trouble figuring out how I should handle user authentication though.
Obviously the API should run over SSL, but the question that's coming up is how should I send the request that contains the user's password: over GET or POST. It's a RESTFUL API, so what I'm doing is retrieving information meaning it should get a GET request. But sending the password over get means it's part of the URI, right? I know even a GET request is encrypted over HTTPS, but is that still the correct way? Or is this a case to break from RESTFUL and have the data in the body or something (can a GET request have data in the body?).
If you pass the credentials in a request header, you will be fine with either a GET or POST request. You have the option of using the established Authorization header with your choice of authentication scheme, or you can create custom headers that are specific to your API.
When using header fields as a means of communicating credentials, you do not need to fear the credentials being written to the access log as headers are not included in that log. Using header fields also conforms to REST standards, and should actually be utilized to communicate any meta-data relevant to the resource request/response. Such meta-data can include, but is not limited to, information like: collection size, pagination details, or locations of related resources.
In summary, always use header fields as a means of authentication/authorization.
mostly GET request will bind data in URL itself... so it is more redable than POST..
so if it is GET, there is a possibility to alive HISTORY LOG
Using ?user=myUsername&pass=MyPasswort is exactly like using a GET based form and, while the Referer issue can be contained, the problems regarding logs and history remain.
Sending any kind of sensitive data over GET is dangerous, even if it is HTTPS. These data might end up in log files at the server and will be included in the Referer header in links to or includes from other sides. They will also be saved in the history of the browser so an attacker might try to guess and verify the original contents of the link with an attack against the history.
You could send a data body with a get request too but this isn't supported by all libraries I guess.
Better to use POST or request headers. Look at other APIs and how they are handling it.
But you could still use GET with basic authentication like here: http://restcookbook.com/Basics/loggingin/
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've seen many questions about restful-authentication but I'm wondering what strategies are being used to keep browser user agents stateless while authenticating to a RESTful web-service.
Doing it with a custom REST Client is "easy": We can use Basic Auth, Digest, OAuth or roll your own (custom headers, tokens, signatures etc). Thus, for machine to machine we are pretty much covered but I'm only interested in authentication with everyday browser user agents (IE, Firefox etc). For example JSON is out since the browser can not render / use it ;)
Here are some of my thoughts in terms of browser limitations:
AFAICS there is no way for a browser to send custom headers such as those used by OAuth? (Right?)
I have a feeling that one should be able to have a login page (html+ssl for example) where the user does a login. (No Basic auth) The browser then captures a token(s) and passes it back the server with each request. The problem I have with Basic Auth is that I do not have a “nice custom login page”. Is the current authentication mechanism to extensible that we can keep it restful?
I'm careful in breaking / relaxing REST constraints because of the risk of loosing the benefits of scalability.
A similar answer here but I have a special case against cookies : (without going to much detail): The way browsers currently work in using cookies is out of the question since the server is in control of the cookies. ("Set-Cookie" header from server side state). The client does not understand or interpret the contents of cookies it's fed and just returns it. The problems is that the client is not in control of the cookie. Thus, yes we can use cookies in a restful way in "custom/machine to machine clients" but it's not the way browsers implements it.
What strategies and best practices are there that you have been using and what are your experiences? Any extra comments?
I think the browser limitations you mention are essentially insurmountable for most use cases. Our personal solution is to have a lightweight non-RESTful layer presented to the user which contains a custom REST client; for example, for JavaScript apps we expose a server-side REST client via JSON-RPC.
If you are using an apache web server, you might want to take a look at this document.