Update1:
Could you give me a short example on how to manage cookies and sessions in play2? (remember me function)
Okay I think I understand the main concept behind the play authentication.
Zentasks uses sessions. I know that sessions are only stored on the server.
And sessions in play2 are already signed. Cookies are not.
What if the users wants to be logged in even if he closes the browser?
I would need to use a cookie.
What should I do?
Do I create a cookie that creates a session?
for example
user has a valid cookie
get cookie val and create a new session
Or do I completely discard sessions and only use cookies instead. Because cookies are not signed automatically by play2 , I have to do it by myself, which I did.
response().setCookie("remember",Crypto.sign(rnd) + "-" + obj.getClass().getName() + "-" + rnd,12000);
(I know I didn't make it secure yet with the secured and http only flag)
I just don't want to invent a new and flawed system. I hope you can clear things up for me how to make authentication secure in play2.
The session scope in Play is nothing more than signed (secure) cookie (and they are stored on client's, not server's side!)
From above docs:
It’s important to understand that Session and Flash data are not
stored in the server but are added to each subsequent HTTP Request,
using Cookies.
so you can keep the logged in state by checking if the session scope's key exists and matches any of your user.
De facto session scope doesn't expire automatically, so your user will be logged in until he'll click on the logout action link (in which you need just to destroy the session's key) (only in some browsers)
This helped me a lot
http://bazaar.launchpad.net/~opensource21/permsec/trunk/view/head:/psec/app
Related
I'm developing a web app that will be used inside Cisco Jabber as a Custom Tab.
In my app the user needs to be logged in. The first authentication is done using Spring SAML (SSO). if this authentication fail then the user fallback to one of those auth process :
- A: directly with his userid (not a real auth but needed for some client)
- B: a login form (auth against client database)
The problem is that some actions are creating popups and with Jabber those popup are opened in Internet Explorer which doesn't have any information concerning my user and thus my app tries to authenticate him again. If SSO works no problem no action required by the user, if that fails auth A works fine but if auth B is selected then I have an issue because I need the user to be authenticated without him entering his credentials.
Is there a way with Spring, Spring Security to copy the session from Jabber to IE skipping the log-in page?
I followed the advice here and tried to set the jsessionid as parameter of my popup url like this:
var logUrl = 'login.do' + (this.user === '' ? ';jsessionid=' + sessionId : '?userId=' + this.user);
var w = window.open(logUrl, number, 'width=800,height=600,resizeable=yes,scrollbars=yes,toolbar=no,location=yes,status=yes,menubar=yes');
The problem is that when the user open the popup, the jsessionid in the url is not the same as the one in Jabber. And if I try to log in with the JSESSIONID of the user in Jabber it doesn't work.
Is there some configuration parameter I haven't set for this to work?
The session is tracked using the JSESSIONID cookie so you could pass this as a URL parameter on referral.
However, there are security concerns around session hijacking to consider with this approach.
For example, you must use SSL/HTTPS.
See this answer for more information.
Solution: We dropped the idea of re-using the session and are now using jwt instead as it achieve basically the same thing for us.
I have IBM WAS 6.1 and Portal 6.1. Also i have a TAI which works when user login/logout in/out Portal. I want to work with HttpSession in TAI. Shortly my task is next: when user logging in i want to save some parameter in memory and as a key i want to use ID of HttpSession (or something else?).
For an example, while user logging id of httpsession is "foo". Than, user logged in and working in Portal, and press Logout button, portal logged out user using internal mechanize and than my TAI catch this request and now i have a http session with Id "bar". So, WAS changed http session. This means i can not user http session to save any parameter, because WAS recreates it for logging out. But i have to save some parameter while user logging in, and use it while he logging out.
Also i can't use Cookies for some reasons. Any idea how i can save ID based on HttpSession?
Or i have to know who(Portal Uid of user) pressed logout button in TAI. It is also helps me to resolve my problem.
UPDATE #1.
Also, for some reason WAS(?) delete custom cookie. I add custom cookie in TAI and WAS deleting it, i can not find my own cookie. Any idea where and why? There also http server beyond was and client, but i checked it - he shouldn't delete it.
I did not resolve question about http session, but i resolved problem with a cookie.
Right cookie:
Cookie cooky = new Cookie();
cooky.setPath("/");
cooky.setDomain("domain.com");
I am confused on the documentation of the javax.servlet.http.HttpSession.
It says:
Sessions are used to maintain state and user identity across multiple
page requests. A session can be maintained either by using cookies or
by URL rewriting.
Now both cookies and URL rewriting are handled by application code in server (i.e. our code).
Then it says relating to when a session is considered as new:
The server considers a session to be new until it has been joined by
the client. Until the client joins the session, the isNew method
returns true.A value of true can indicate one of these three cases:
1. the client does not yet know about the session
2. the session has not yet begun
3. the client chooses not to join the session. This case will occur if the client supports only cookies and chooses to reject any cookies
sent by the server. If the server supports URL rewriting, this case
will not commonly occur.
I am not clear on when it is considered/meant that the client has joined the session.
I mean if I don't use cookies from my web application (or URL rewriting) and I have the following:
POST from IP A to server
200 OK from server to A
POST from IP A to server
In step 3 will the session.isNew() return true or false? It is not clear to me from the doc.
Will it return false (i.e. the session is not new) and I will have to call session.invalidate() in order to create a new session?
The reason this confuses me more is because I am debugging a piece of code where the client is an HTTP application but not a web brower and I see that in step 3 the session.isNew() does not return true although there is no cookies or url rewriting in the server code.
So I can not figure out what is going out under the hood.
Any info that could help understand this?
Here is a nice example of Session Tracking
Client has joined the session means that client made subsequent request and included session id, which can be recognized by your webserver. If cookies are enabled - jsessionid will be passed with cookies, otherwise - it should be include in the URL itself - like this http://localhost:8080/bookstore1/cashier;jsessionid=c0o7fszeb1.
In JSP c:url from Core Tag Library will handle URL rewriting for you.
In case of B2B communication you have to obtain session id by yourself and include it in subsequent requests manually.
Example:
POST from IP A to server
200 OK from server to A
A obtains session id from the response
POST from IP A to server and includes obtained session id
UPDATE:
Consider reading a great article - "Web Based Session Management: Best practices in managing HTTP-based client sessions." It's a general overview of how HTTP sessions can be emulated and is not tied to Java.
How can we manage session Object if the cookies is disabled ?. how url encoding is used for this?
The servlet container will handle this for you. If you look at the url in the first time you hit your site, it will have used URL re-writing to append a JSESSIONID to the URL.
This is because the first time the server responds to the client it doesn't know if the client supports cookies or not. It has also written a cookie with the session id in, so on the second request it checks for the cookie and if present stops using URL re-writing, if not it carries on.
You have to use encodeRedirectURL in response object, Please refer this blog it will helpful for you.
http://mytechbites.blogspot.com/2009/08/servlet-session-management-when-cookies.html
it adds jSessionId at the end of URL to map request with session you probably need to configure your server for that too
Use HttpServletResponse.encodeURL() to append jsessionid to your URL, but it is considered harmful.
Find more details here
HTTP Sessions are the recommended approach. A session identifies the requests that originate from the same browser during the period of conversation. All the servlets can share the same session. The JSESSIONID is generated by the server and can be passed to client through cookies, URL re-writing (if cookies are turned off) or built-in SSL mechanism. Care should be taken to minimize size of objects stored in session and objects stored in session should be serializable. In a Java servlet the session can be obtained as follows:
HttpSession session = request.getSession(); //returns current session or a new session
Sessions can be timed out (configured in web.xml) or manually invalidated.
I do not have much experience in Java authentication frameworks and authentication workflow in general (only some theoretical knowledge), so for educational purposes I'm trying to create this type of authentication for my HTTP application:
Client Posts login+password to /login.
Shiro logs in the user by given credentials. Server returns client his sessionId.
Client requests some kind of resource /myresource?sessionId=1234567.
Shiro logs in the Subject by given sessionId. Then server does the regular workflow of getting the /myresource (with Shiro managing method-level access rights).
Basically I have these questions:
I guess I have no need for HTTP sessions nor Servlet sessions. Shiro has it's own session manager which is enough for my needs. Am I wrong?
Is it good practice to give client the real sessionId or should I send some kind of sessionToken (which is resolved to sessionId on server side)?
How do I login the Subject using sessionId (which the client should store locally)?
Are there any other things I need to know before doing this kind of authentication?
Thanks in advance.
I guess I have no need for HTTP sessions nor Servlet sessions. Shiro has it's own session manager which is enough for my needs. Am I wrong?
No, you're right. That's why Shiro is awesome. From documentation:
Shiro's Session support is much simpler to use and manage than either of these two [web container or EJB Stateful Session Beans] mechanisms, and it is available in any application, regardless of container.
e.g.
Subject currentUser = SecurityUtils.getSubject();
Session session = currentUser.getSession();
session.setAttribute( "someKey", someValue);
quoting from the doc: getSession calls work in any application, even non-web applications
Is it good practice to give client the real sessionId or should I send some kind of sessionToken (which is resolved to sessionId on server side)?
It is a bad idea to send plain sessionId. Specially, if you're sending data over unencrypted network. Either use something like HTTPS or use something line NONCE.
And, a side note, if over http/s POST data instead of having it in URL.
How do I login the Subject using sessionId (which the client should store locally)?
You meant how could you authenticate the subject once you have session ID? You can simply,
from the doc,
Subject requestSubject = new Subject.Builder().sessionId(sessionId).buildSubject();
Are there any other things I need to know before doing this kind of authentication?
Yes.
Read Shiro's Session Management
Lean about MITM Attack
About HTTPS and SSL
Some on Hash functions this, Apache Commons DigestUtils and may be this
Updates
About that subject authentication part - will it make the newly created Subject the currently authenticated subject? If not, how do I make it the "current" subject?
If you're talking about new Subject.Builder().sessionId(sessionId).buildSubject(), it will not. And I do not know how to set it as currentUser for the thread. Shiro's JavaDoc says,
[this way] returned Subject instance is not automatically bound to the application (thread) for further use. That is, SecurityUtils.getSubject() will not automatically return the same instance as what is returned by the builder. It is up to the framework developer to bind the built Subject for continued use if desired.
so, it's upto you how you bind the subject in current thread or further use.
If you were worried about how SecurityUtils.getSubject(); thingy works, well, in web-container context, it uses simple cookie to store your session-data. When your request comes through Shiro filter, it attached the current subject to request for it's life cycle (current thread). And when you as getSubject() it simply gets the Subject from request. I found an interesting thread here.
about nonce part: If he sends me some kind of hash instead of his sessionId - I won't be able to decode it to get real sessionId (to authorize him with that). Am I missing something here?
Nonce part -- it's a pain in the neck. Now rethinking, I think doing NONCE is just overkill. Let me explain some, anyways,
User logs in first time with his user-name and password. Set userid, nonce (say, UUID), and HASH(sessionID+nonce) ,call it hash1, on client side. Say, in cookie. Store this nonce on server side, may be in DB or in a Map as user_id <--> nonce,session_id
On subsequent request, make sure you passback userid, nonce and the HASH.
On server side, the first thing you will do is validate the request. Get the sessionId and nonce stored in the hashmap or DB based on user_id that was sent by the client. Create a hash, HASH(sessionId_from_db+nonce_from_db), call it hash2.
Now, if hash1 matches hash2, you can validate the request and since you have stored current sessionId on server side, you can use it. On request completion, set new nonce in cookie and on server side.
If you go through 1 -- 4, you'll realize you wouldn't require Shiro for authentication. (:
So, I am taking my words back, NONCE is not applied in this case unless you are too freaky about security over performance.
Why do MITM attack matter to me? My client (javascript ajax code) fetches data from it's server via ajax. So I do not think I should care about MITM in any way.
I think it should matter to you. MITM Attack means your requests/responses are being chained via a machine (MITM) to your router. If it's an unencrypted request, it's all plain text to the MITM. He can see all your requests... and possibly spoof the requests and may hijack session. let me find some example.... http://michael-coates.blogspot.com/2010/03/man-in-middle-attack-explained.html