I'm very new to enterprise java web app development, so please be gentle.
A co-worker and I are working on a small application for our company, and this will run entirely within the private network which has zero exposure to the big internet. Using Spring and writing the server side as a set of REST APIs.
Regarding REST authentication; I have done some research, including this topic which was very helpful.
I plan on using HTTP basic authentication over SSL, but I am worried about performance. Our company has an LDAP user-lookup authentication service. With REST being stateless, obviously every REST call needs to be authenticated. If LDAP is slow for some reason, every action in the application will be impacted.
I had an idea which I'm wondering if makes sense:
- Have the user log in once, then we generate a unqiue token that gets stored in a session table - including the user's userid, log-in timestamp and last-action timestamp.
- The token gets sent back to the client, and it is up to the client to continue to re-send it back with every REST call (we could stick it into the HTTP authentication header).
- The token is checked for validity before any REST call is executed.
- With every successful REST call, the user's last-action timestamp is updated in the sessions table.
- Another thread runs on a 60 second cycle, which checks for elapsed time since last-action for each user -- and if anyone is inactive for a period of time (e.g. two hours) -- their session token is wiped out.
Is this a reasonable approach? I know I'd have to handle (or disallow) multiple logins from a single user from different clients; haven't thought through that yet.