I am working on a webapi project which of course is supposed to be stateless.
The point is that it requires authetication and the majority of it's services is available to logged in users.
The catch is that there are several pieces of information about that user which should be used on all subqsequent calls to the legacy backend.
Should I force the clients to send back all those parameters on each request? (doesn't seem fair)
Should I use a caching on the webapi side - this is tricky as currently there is no out-of-memory distributed cache in use in the deployment environment....
What options do you see?
You could choose to issue the user some kind of session token on the first call. The server could then use the session token to authenticate the user and remember the settings for that session on subsequent calls.
You can read more about managing sessions in a stateless environment here:
http://en.wikipedia.org/wiki/Session_management
Related
I'm getting into the world of fullstack development and I'm trying to develop app which front is completely separated from backend (front is being served from node server and backend is java).
Now, the issue - how should I get about securing my app?
I'd like to have many fronts and many backend instances connected through load balancers and I'd like to keep all the state on client, so I can without any issue switch to another backend server and continue as nothing happened.
Currently I'm using OAuth2 tokens but I'm concerned about security and stealing the tokens, which are completely stored in cookie on user side. Also, The app (obviously) stores those tokens somewhere, so another instance of my backend app wouldn't accept the token. In best case scenario I can implement some mechanism that would automatically request a new one and in worst case I'd have to login again. I don't want that to happen.
Also, here I have a problem with social auth. Allright, I'm receiving token from Google on front, but giving it to backend and creating a user there is major pain, I have to write a lot of code manually to create such user and save it.
And again, I'm not certain about security level of this solution.
So the question is basically - currently, what is the best way to secure an app which should have completely separate front and backend, which would have no issue with switch backend server between requests?
As regards tokens being stolen from the Client: you can't do anything about this. It is up to the client to protect themselves. What I mean is, if you need a username and password to access a service, and the Client is infected with a key-logger, and a hacker steals those credentials, there is nothing you can do on the server side to protect against this.
As regards your idea of multiple back-ends, this is a common feature of any system with multiple application servers. For example, if you have multiple web servers and want any request to be routable to any server. For this, you need a central database which stores any information which needs to be shared. It's slower, obviously, but much more resilient.
I have been asked to use ember for front end and java rest services as the backend. I am trying to figure out how to manage session for a particular user.
i know there are couple of options like storing in the local store, cookie but they are error prone as some users might disable those features. I want to know what is the preferred approach in normal enterprise apps.
Mine app is simple 15 page app. i need to capture user, and some profile details.
Session are usually more of server side part. You have to just make sure whether the provided session is available or not for every transformed route and request. There is a library which takes care of authentication and authorization in ember https://github.com/simplabs/ember-simple-auth.
I have a COTS application(PLM application) which has provided few SOAP APIs to access. Since this SOAP API is highly complex, we are developing a easy to use REST wrapper service. Before invoking any API in my COTS application, authentication API needs to be invoked. In my REST wrapper web service, I have a login resource which invokes COTS SOAP login API. To keep things simple for my API users, I store the logged in user details in user session. In every other REST resoruces, I retrieve the session and check whether session has user details. If yes, I proceed and invoke the SOAP API. if not, I return proper HTTP status code. I use Apache CXF for service and client. I mandate my APIusers to maintain the session in the client like this
WebClient.getConfig(client).getRequestContext().put(Message.MAINTAIN_SESSION,
Boolean.TRUE);
In every REST tutorials, it said REST is stateless. I am doubtful whether what I am doing is correct as per REST standards. Please suggest. Thanks
Basically the idea of REST is a stateless interface. However it is common practice to use some kind of authentication for API calls since most of the time not all resources should be public (e.g. the timeline of a twitter user over the twitter API)
Therefore it is ok if you do some kind of authentication and validate a session on further requests (or maybe authenticate with every single request, e.g. with HTTP Basic Access Authentication) to check if access should be granted.
Not part of this and not the idea of a RESTful API would be to store complex session information that would really make the whole thing stateful. This for example includes storage of information of an older request for processing together with one following later.
client.getRequestContext().put(Message.MAINTAIN_SESSION, Boolean.TRUE)
This code causes cookies to be maintained in that specific client only.
If you want those cookies be available in another client, it needs to be programmed.
And if the second client receives additional cookies and you want those cookies available in the first client too, how is that possible?
I need something like a root client that maintains cookies of all sub clients. All cookies must be shared among all clients. Like a shared cookie repository for all clients. Does anyone know how to achieve this?
I know that REST is not supposed to use HttpSession.
From the other side, the REST service is running within a servlet container.
From what I saw, the HttpSession object will be created only when:
HttpSession session = request.getSession();
code is executed. Is it always the case? Besides using JSP?
My question is: will be HttpSession objects be created when the REST method is executed or not?
Let's say I use the JAX-RS framework, if it can make any difference.
If such objects are not created, it actually can mean that the size of the server memory may not grow irrespective of how many clients use it the server.
HTTP sessions are actually used quite often with REST interfaces, but should never contain anything truly critical. Thus, they can be used to contain the fact that you've authenticated or what your preferred default ordering of some list is; in the former case, you could also support other authentication mechanisms at the same time allowing fully stateless operation, and in the latter you can easily also support explicit overrides. So long as you don't require a session — well, under the assumption that your site was using HTTP BASIC auth for the sake of argument; if you're using OAuth then you need sessions enabled to stop performance from being crippled — then you're still potentially reasonably close to RESTful (in this area for sure; REST is not “don't use sessions” after all).
Is there a concern about how long a session lasts before timing out? Well, maybe but not really. A session is really an object that you've mapped into some database table, and you can configure the expiry policy on them so that they last long enough to support effective use without being over-burdensome. Which depends on how many clients use the site at once, what their usage patterns are, and what hardware resources you've got available (of course).
I think this is the limitation of Java EE framework at the moment I haven't seen it done otherwise any other server yet. If you need to have a container managed security-constraint a session will be created.
That being said you do not require to implement your code to use container managed authentication. People do implement authentication login/mechanisms themselves like Shiro and what not.
If you're concerned about scalibility, you may have to handle the authentication on your own. However, before you continue with this path consider the following... how many people are you expecting to use your app? Unless you're some really big and popular service like Facebook or Google etc, present hardware/cloud offerings should be able to handle your load with HTTP Sessions with a lot of room to spare.
However, if you wanted to do it an implement yourself then I suggest the following:
unauthenticated client passes credentials (via WWW-Authorization is the easiest to test with)
credentials are validated and a token is returned. The token is an encoded encrypted string containing client ID, an expiration and a reauth token. This token is passed back to the client with Set-Cookie
Client makes future requests with the Cookie containing the token
The token can be used as long as it hasn't expired, this would just be crypto calculations on a server node and thus can be scaled across multiple servers if needed there's no single data store to deal with.
The reauth token can be used to generate a new token for the client should it expire (this is useful for user applications where the interaction can last for minutes).
You can add an enterprise cache to store which ones are still valid at the expense of an extra backend call.
I have a high-level/conceptual question about Shibboleth.
I'm working on the front-end (running Drupal) of a data-driven web app. End-users interact with the front-end to construct data queries, which makes background requests to a caching/archiving data proxy (the "data retrieval service"), which in turn either delivers data from its cache or goes out and queries still more services ("out there") which have desired data. So far so good... it is ornate, but only as ornate as the problem we're trying to solve.
Here's the wrinkle: Some of services queried by the data retrieval service want to implement user-level authentication, so that some users may access their data, but others cannot. For organizational reasons, our identity and authentication mechanism is likely to be Shibboleth.
So, here's my scenario: a user logs in to the frontend using Shibboleth. Now, can my frontend, and in turn, the data retrieval service, authenticate against against external services as the user? And if so, how does that work in practice (what authentication data gets passed from server to server)?
Yes it can - you service has to exist in the identity provider (how it is set up is up to you)