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.
Related
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 have a spring web app hosted on amazon and I am facing login attacks from some automated machines. From my logs, it is clear that they are bypassing login page, and are using something like :
curl --data "j_username=xxx&j_password=yyy" http://www.mysecureurl.com/j_spring_security_check
My question is how to prevent such attacks. Is there a way I can block such logins which are not coming directly from login page via some spring configuration ?
I will then implement further security measures like captcha, lockout-after-3-wrong-attempts etc when user tries from login page.
You can implement the a Cross-site Request Forgery (CSRF)- Nonce-Token Pattern.
In other words,
generate a random token (for every user an different).
put this token in the user session
an add it as a hidden field in the user login form
if you receive a login request than the check if the submitted token matches the token form the session - if not then send them a access denid
BTW:
you can use this pattern not only for your login page, but for all requests that change the server state. (to prevent CSRF-Attacs)
Spring Security >= 3.2 has a build in CSRF-Prevetion
If all requests coming from the same IP address you can use hasIpAddress expression:
<security:intercept-url pattern="/secure" access="isAuthenticated() and !hasIpAddress('11.11.111.11')" />
It is more temporary hack, because attackers can change their IP.
Here is how I solved my problem, thanks to all the answers above.
1.Added a custom filter to my spring security :
<custom-filter position="FORM_LOGIN_FILTER" ref="loginFilter" />
2.In the login controller, generated a random string and put that in http session
String random = UUID.randomUUID().toString().toLowerCase().replaceAll("-", "");
request.getSession().setAttribute("userKeyInSession", random);
3.Also passed this random key to login page so that the login jsp can submit this as hidden parameter along with form submit.
model.addAttribute("userKey", random);
return "login";
4.In the LoginFilter, I now do a simple string comparison between the request parameter and the random value in the session. If they do not match, I reject and do not proceed with authentication.
More to do: Captcha etc for preventing attacks from UI now..
Looks like you are using the default request login parameters provided by Spring-Security.
The default name attribute and password attribute value is j_username and j_password.
So if you change your login page's username and password parameters name attribute to something specific to you app , then you will be able to avoid such attacks , because in that case only you will be knowing the actual values attribute name and password and no one else and thus no one will be able be able to send http hack request to you app.
I have a web application that I deploy using JBoss 5.2. In order for a user to use the application, he/she must authenticate with an LDAP server (using simple authentication) with a username and password. This is all done through setting up the login-config.xml for JBoss and providing a <login-module> with our implementation.
The problem comes in here: After having logged in, I have a scenario that requires the user to provide a username & password when a particular action is performed (which I will also authenticate with the LDAP server). I want to be able to reuse the same mechanism that I use for authenticating the user into the web application.
My form to log in to the application posts to j_security_check so in accordance with this, I was trying to send a request to j_security_check but JBOSS returns a 404. From reading around a bit, I've gathered j_security_check cannot be accessed by any arbitrary request and must be in response to a challenged request to a secured resource.
So then, how can I authenticate the second set of credentials the user has provided with the same LDAP server?
EDIT:
To clarify, the question is how to send the user's credential inputs to the LDAP server for authentication. Grabbing the input from the user, etc. is all done. All that is left is to take this input and send it to the LDAP server and get the response (which is where I am stuck).
If it helps to mention, the login to the web application uses a custom class that extends UsernamePasswordLoginModule.
So, after lots of research, I ended up finding a solution for JBoss environments (which is what I'm using).
Once you capture the user's credentials, you send them to your server via a POST/GET and your server can perform the following to use whatever authentication policy you have configured (in login-config.xml) to verify the credentials:
WebAuthentication webAuthentication = new WebAuthentication();
boolean success = webAuthentication.login(username, password);
To expand on this, I was also able to check the user's role/group via the HttpServletRequest (which is passed into my server-side handler):
boolean userIsInRole = servletRequest.isUserInRole("nameOfGroup")
The spring security documentation explains it
Wanted to add another answer for JBoss 6.2+, where WebAuthentication no longer exists.
I've used the creation of a LoginContext to achieve the same result:
String SECURITY_DOMAIN_NAME = "ssd"; // the security domain's name from standalone.xml
String username = "user";
String password = "password";
LoginContext lc = null;
try {
lc = new LoginContext(SECURITY_DOMAIN_NAME, new UsernamePasswordHandler(username, password.toCharArray()));
lc.login();
// successful login
} catch (LoginException loginException) {
// failed login
}
And the use uf lc.getSubject().getPrincipals() to verify roles.
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
What you usually do in a GWT application to sign in using OpenID is the following:
LoginInfo loginInfo = new LoginInfo();
UserService userService = UserServiceFactory.getUserService();
loginInfo.setLoginUrl(userService.createLoginURL(returnToUrl));
return loginInfo();
Where returnToUrl is the current URL you like to redirect back after verification. This works fine, if returnToUrl is a simple URL like http://mydomain.com/go/here
But as my application runs as a GMail contextual gadget, it is wrapped in a frame that gets its content from a google proxy (googleusercontent.com). So this is the - a little mor complexe - URL within the frame I like to redirect back to:
https://jtphjhg2q9h3ul31ifsbvm5hv7717h49-a-gm-opensocial.googleusercontent.com/gadgets/ifr?url=http%3A%2F%2Fgorgactsgadget.appspot.com%2Fgorgadget%2Fcom.innubili.gorgacts.client.Gorgadget.gadget.xml&container=gm&view=card
During the OpenID registration the user gets redirected several time and if the returnToUrl is not properly url encoded parts of it get lost.
As I found out here, you even in some cases have to double-encode the URL. But this time I'm not able to encode the URL correctly.
So, my questions:
Do you have any hints what an OpenID-return-to-URL should look like in a Gmail contextual gadget?
Or maybe a little simpler question: Is there any other way, I can retrieve the email of the current logged in GMail user?
You cannot use openId login from within a Gadget because your gadget is proxied by the gadget container.
You have to open up a popup window to do the openId login and associate the opensocialId to your openId identity on the server. You have to persist the relation between openSocialId and the user identity on the server. From then on, the gadget knows its identity by requesting the relation of its opensocialId.
see also http://code.google.com/googleapps/marketplace/best_practices.html#gadget_sso