I have an application deployed to Google App Engine. Within the application, there are 2 roles: standard user, and administrator. I have form based authentication setup, and the URL's that require authentication (for example /admin and /account) are setup to require any role (*), just so I can be sure that Google has authenticated them. I have a filter setup for the admin path as well as the account path that talks to backend business logic to see if the user has an account within my application before forwarding them to the page they requested, or redirecting if necessary.
This seems cumbersome, in that for each request, the filter uses the UserService to get the google user in order to determine whether or not the person authenticated by google has an account within the application. I know that within the context of an application deployed to a traditional application server, I could actually define the application level role required to access a url, and since the application server would know about the roles/users for the application, that would be sufficient, but since google is handling the authentication, would I be correct in assuming that I have to handle the access requirements on a per request basis, as I am now with the use of filters? I chose to use filters to try to keep the actual servlet 'cleaner', so that I know that when a client request reaches the servlet, they have been authenticated and are authorized to access those resources.
Would it be wise to carry that data around (whether a user is authenticated and whether or not they are an admin or standard user) in a session? That's the only other alternative I can come up with. I'm not sure how expensive it is to access the UserService for every single request, because that is in turn accessing the datastore. I would imagine there has to be a better way to handle authentication.
Not really sure if it's an optimal solution but what we do now is store a User session (our own implementation, not GAEs) and we cache it aggressively using Objecitfy's cache feature. That way we only hit the datastore on login/logout and most queries after that are virtually free (because of the use standard session time on our app, cache flush is not really a concern)
Related
We have an existing legacy web application(Servlet+jsp+spring+hibernate) and we are going to develop some new features of the application using a new stack (angularjs+Spring mvc). Currently suggested approach is to register a new servlet and develop the new features in the same codebase, so the authenticated users will have access to the new functionality we develop in the system. Is there a better way of doing this as a two different web applications (without SSO) ? Can two web applications be secured under the same form based authentication settings ?
I think architecture and security usability is very important before dive into something.
If both apps use same login, then I assume the newer application is more likely a service oriented application. Ex: RESTful
Authorization may be an issue. Ex: Legacy app is used by user set A, new one is used by both user set A and B.
Otherwise you can use a shared database for example MongoDB to store your login info i.e token.
When you log in, return that token and use for the other service via angular client. When you log out remove any token for that user session. You may also need to concern about token expiration.
However you have to refactor your legacy system in someway to use a token. If it is not possible, you can use session sharing which is handled by the the container if the the both apps are running under same container. Ex: Tomcat. But now it may very hard to integrate with a native mobile app if you are hoping to do so.
Sharing session data between contexts in Tomcat
From the point of Spring security and angularjs, authenticating via form is just an http POST with content type being application/x-www-form-urlencoded. One difference is the response to a non authenticated request, for one response should be a http redirect (jsp, to a login page), one with an unauthorized code (for angularjs). That could be handled with a custom AuthenticationFailureHandler or on the client side. A similar difference may occur for the successful login redirection.
We are using Spring Security and it is working fine in the single web application. Now, I need to create another Web application with Spring security. In the first application the user can sell his/her stuff (e.g. EBay). The second app which I am creating now, it is for general users where he can save his general preferences, searches, save some items he looked at etc. He may/may not be the existing user. So the difference between the two users are:
User 1 (existing user): Can post his stuff for sale.
User 2: He/she should be able to login. Save his general activities etc. & if he/she wants to sell his/her item, he/she needs to go thru the additional steps for verification.
All this cannot be done in just one application due to some reasons. My question is on how to handle the security? Should I create separate security filters for each applications or is there a way to use common security implementation who can manager both of these application. Please provide your feedback, I would really appreciate it.
if you wrap both components in two different webapps, each will have his own spring security web filter infrastructure.
So in principle there will be a security session for each web application, to be backed by whatever authentication system you use.
If you use JDBC then the user would have to login twice.
If you want your customers to only login once, you can for example use a token based system.
When you cross link from webapp 1 to webapp 2, you could hook the links up to a redirect servlet.
The servlet then generates a token, persists it in a database and forwards the user with the token in the url to the other webapp.
In spring security you can then implement your own PRE_AUTH_FILTER which reads out the token, verifies if it is persisted in the Database.
For security reasons you should make these tokens only one use.
I have developed a web application on Struts2 and used JSP. I want to develop a login system and so cookie management for my web application. Everybody can see every page and there is no authorization for my website.
My question is that what are the steps of my work.
1) Login system
2) Cookie management
3) Authorization
will be done but where I should start and is there any good documents of that steps(for every step of what should I do)?
You can implement this using Sessions, which means you won't have to work with cookies (at least directly). Also keep in mind the difference between authentication (checking identity of a user) and authorization (checking users access rights). I usually implement:
a Login action (which authenticates the user in some way, and saves something to the session which I can latter check to see if the user is logged in...eg. a User object)
an authorization interceptor (which filters each request and checks that user is logged in and has access rights for that particular request....if not forward to login form).
Also keep in mind that this is a do-it-yourself quick way to do it, if you plan anything more you are better off with a security framework/lib of some sorts.
The cookie managment in Struts2 is an orphaned feature. There are ways of reading them using the framework, but no way to write them. Since you have to go directly to the ServletResponse to write cookies, you may as well use the ServletRequest directly to read them.
Check out this: http://www.dzone.com/links/r/working_with_cookies_in_struts_2.html
In my applications I use JavaScript for handling cookies, is more practical, and works well for me.
We are planning on developing a layer of REST services to expose services hosted on a legacy system. These services will be used by a classic web application and native mobile phone applications.
This legacy system is secured in such a way that an initial username + password authentication is required (a process that can take 5 to 10 seconds). After the initial authentication, a time-constrained token is returned. This token must then be included in all further requests or else requests will be rejected.
Due to a security requirement, the legacy security token cannot be returned outside of the REST service layer. This means that the REST service layer needs to keep this token in some form of user session, or else the expensive username + password authentication process would need to be repeated for every call to the legacy system.
The REST service layer will be implemented using a Java 6 + Spring 3 + Spring Security 3 stack. At first sight, it looks like this setup will run fine: Spring-based REST services will be secured using a rather standard Spring Security configuration, the legacy security token will be stored in the user's HTTP session and every call will retrieve this token using the user's session and send it to the legacy system.
But there lies the question: how will REST clients send the necessary data so that the user's HTTP session is retrieved properly? This is normally done transparently by the web browser using the JSESSIONID cookie, but no browser is involved in this process. Sure, REST clients could add cookie management to their code, but is this an easy task for all Spring RestTemplate, iPhone, BlackBerry and Android clients?
The alternative would be to bypass the HTTP session at the REST service layer and use some other form of user session, maybe using a database, that would be identified using some key that would be sent by REST clients through a HTTP header or simple request query. The question then becomes, how can Spring Security be configured to use this alternative session mechanism instead of the standard Servlet HttpSession?
Surely I am not the first dealing with this situation. What am I missing?
Thanks!
There's nothing magical about cookies. They're just strings in HTTP headers. Any decent client API can handle them, although many require explicit configuration to enable cookie processing.
An alternative to using cookies is to put the JSESSIONID into the URL. I don't know anything about spring-security, but it seems that that's actually the default for at least some types of URL requests, unless disable-url-rewriting is explicitly set to true . This can be considered a security weakness, though.
Unfortunately authentication is highly problematic -- a bit of a blind spot in terms of web standards and browser implementations. You are right that cookies are not considered "RESTful" but purists, but even on fully-featured browsers avoiding takes quite a bit of hackery, as described in this article: Rest based authentication.
Unfortunately I haven't done any mobile development, so I can't suggest what the best compromise is. You might want to start by checking what authentication models each of your targetted platforms does support. In particular, two main options are:
HTTP authentication (ideally "digest", not "basic")
Cookies
One possibility would be to provide both options. Obviously not ideal from a technical or security point of view, but could have merits in terms of usability.
I'm working on an existing j2ee app and am required to remove some vendor specific method calls from the code.
The daos behind a session facade make calls into the ejb container to get the user's id and password - in order to connect to the database. The user id and password part of the initialContext used to connect to the server.
I am able to get the userid using sessionContext.getCallerPrincipal()
Is there anyway to get to the SECURITY_CREDENTIALS used on the server connection or, is there a way to pass information from the server connection into the ejbs (they are all stateless session beans).
This is a large app with both a rich-client and web front end, and in a perfect world I'd be happy to go back and re-architect the entire solution to use J2EE security etc - but unfortunately, that is not realistic.
I can't give you a generic solution, but this is what has worked for us. We have the app server connect to LDAP as a specific user that has the ability to request credentials for other users. Then we have some generic security code that we can use to request a users credentials from inside the session beans, based on the users identity from their initial login (just as you are doing it via getCallerPrincipal()).
We also place the users identity in a thread local variable, so that classes down the call chain from the EJB do not have to be "container aware". They simply access the identity from the thread local and use the security classes to look up user profile information. This also makes it easy to change the implementation for testing, or even something other than LDAP lookups.
Other conveniences we created were a JDBCServiceLocator that retrieves connections with user/password for the current user. So the developer does not have to explicitly code the security lookups at all.
Normally the Java EE security model will not allow the retrieval of the user password, for security reasons. But it depends on the implementation. Some vendors provide methods to retrieve this kind of information, but if you rely on such implementations, be aware that the portability of the application will be compromised.
One common approach is to write a servlet filter to intercept the login request and save a copy of the credentials, to be used later. If your application doesn't use the Java EE security infrastructure, this could be easily implemented. That's because some vendors prevent you from filtering an authentication servlet.
Robin,
Sounds like what I was planning. I figured I'd make a call right after a successful server connection to load the credentials into a threadLocal variable on my connection class. I was hoping there was an easier way - but I guess not.