I am developing a web application with two major division, one is the Wicket side of the application and the Restlet side of the application which are quite decoupled. Although the code resides in the same project, I want to decouple it, so the Wicket part calls on the REST services exposed by the Restlet backend.
Now the issue is with the Session, in the Restlet part, there is a Shiro component which does the authentication et. al. when /login is accessed and the correct username & password pair is supplied.
The question is, what is the approach such that Wicket part of the app would know about the session user currently logged-in in the Restlet part with Shiro?
If your Restlet server part shares same web session provided by the container with your Wicket app, you can access it in Wicket with:
((HttpServletRequest) RequestCycle.get().getRequest().getContainerRequest()).getSession()
Which gives you javax.servlet.http.HttpSession provided by Servlet api. Your Wicket's session which extends org.apache.wicket.protocol.http.WebSession is stored in this session under wicket:wicket.yourapp:session key along with other data set by you, or libraries you use outside Wicket.
I don't know Restlet and how you propagate session there, but I assume you will a need dependency to Servlets in your Restlet / Shiro part, which stores data in session.
Edit: Checking Shiros Session interface javadoc:
//A Session is intended to be managed by the business tier and accessible via other tiers without being tied to any given client technology. This is a great benefit to Java systems, since until now, the only viable session mechanisms were the javax.servlet.http.HttpSession or Stateful Session EJB's, which many times unnecessarily coupled applications to web or ejb technologies
Considering this the above proposal will not work, but it sounds you should be able to easily access Shiros Session object, if you add Shiro dependency to your Wicket part.
You create a new HttpServletRequest to your Restlet back-end, so it will create a session between your front-end and back-end and not use the current session between the users browser and the front-end.
Only way this will work if you try to perform session hijacking in your application to be able to get the user session in both components.
Related
I want to use a cookie based HttpSession in a serlvet container. All session data should be stored inside the cookie. It seems to be uncommon within servlet applications. In Rails (Session) and Playframework (Session), this kind of session handling is the default. Why is this so uncommon?
In concrete I need a solution for JBoss EAP6 (without session scoped beans). I found two implementations based on serlvet filters:
Stateless Servlet Filter "This filter is still in a beta status." 2013
java-stateless-http-session No references for usage and no commit for more than a year. No tests.
Do you know any alternatives?
(If possible I don't want want to discuss pros and cons in general)
It is uncommon in Java EE to have session data persisted in cookie ... because HttpSession is implemented in all servlet containers.
In cookie persistent sessions, you have a limit in size, and you must use signed data to avoid manipulation of session client side. You must crypt data if you want to keep sensitive informations in session. And all session data is exchanged with every request and response. Those limits go away with HttpSession.
The highest interest of cookie persistent sessions is that you can have a farm of multiple servers that can respond to any request, because the session is contained in the request. But this can be done in Java EE by using sticky sessions at a reverse proxy level (because you have reverse proxies in almost every serious data center) : the reverse proxies know about the session and pass a request to the server that holds it.
Some Java EE servers have even a notion of shared sessions.
IMHO it is not that is would be very hard to implement a cookie persistent session in Java, it is simply that for professional usages, it has not been found as important enough.
We are developing an Enterprise application with the following technology stack:
Websphere Application Server
Spring (Webflow (Session in View pattern), JPA (Hibernate), Core)
DB2 osZ
Frontend (JSP Rendering HTML5 (CSS 2.0), Ajax in combination with webflow, JQuery)
Multiple Single Pages design combined by using webflow for supporting
subflows
Development Methodology
- Domain Driven/Component Driven Application
- Test Driven Development
Current Situation
Our domain model has very deep domain class hierarchy and therefore we decided to use webflow to allow deep class navigation in sub flows.
We are using the “session in view pattern” because there are many screens reflecting the class hierarchy of the domain model.
This worked very well because of having the backend managing session scoped data for the frontend.
What do we want to do next?
Single Page Design
Control User data in session
Control User data across screens
Support multiple instance of a browser in one user session
Want to be able to talk to the backend (Enterprise Java/Spring) to
retrieve data and persist
Support more state-of-art user experience
Technology Stack
Websphere Application Server
Spring (Webflow (Session in View pattern), JPA (Hibernate), Core)
DB2 osZ
Frontend (Angular, JQuery, Bootstrap 3)
So the discussion internally is how to integrate Angular?
Should we give up Webflow and solve everything with Angular?
Does a mix make sense?
We have taken the following chart as a reference:
http://vschart.com/compare/angularjs/vs/spring-framework
We know what both frameworks are able to do, and know how to make them work. We are interested in other teams experience on how to integrate Angular? Did someone ever mix Webflow and Angular?
We are interested to see some best practices and how teams have transitioned to either framework or keeping both?
Thanks for input,
Andrew
I suggest you to check the Java library thymeleaf in order to get directly the benefits of HTML5 which you can easily add AngularJS and build on top of it (with bootstrap if you need it), and use Spring Security for Auth & session management.
As loose coupling at all levels (front-end included) is most of the times desirable, try to avoid technology mixing (WebFlow & AngularJS in this case) where doesn't makes sense.
Last thing, you and your team can discuss the possibility to develop an Angular based single page application which consumes a server side API coded in Java.
It is too late but might be useful for someone looking for this sort of answer.
I would recommend
Angularjs SPA(single page application) and use html template instead jsp.
Implement Token based authentication rather session based and implement restful spring web mvc api.
web flow/navigation can be controlled using the Angular services or browser's localstorage. I would recommend Angular services to manage app state instead browser localstorage.
And obviously bootstrap 3 to make the UI pretty.
Example implementation: jhipster
I have an external SOAP web service that attaches to our services layer inside the application. For the Web 2.0 application, the services layer uses the session to store the user's "key chain" or the things a user can do in the system.
Now I'm trying to figure out how to do the same thing with my web service client to our services layer. The problem is that the web service URL can't contain a cookie that holds the session ID. (If I'm wrong, please say how and I'll do it that way.)
When the web service client connects the first time, I require a login and generate a security key that uniquely identifies that user and will expire within a certain period requiring them to login again.
I'd like to find a way in my endpoints to re-attach to the proper session for that security key and then the security will work automatically.
My endpoints are currently being served from tomcat.
How can I get there from here?
All input appreciated.
I ended up using REST to come back into our webapp through the URL so that I have a session. I connected to it that way.
General Case: A simple application that exposes its services through EJB (3.1) - most of them Stateless Sessions beans (nothing funcy here) and SWING based clients that, call through remote interfaces these services and do what they have to do.
Security: I want to authenticate/authorize this cycle of calls and of course protect my services. The obvious answer would be to use JAAS in the server and any custom wiring setup on the underlying server. That is still an option
Apache Shiro: So lots of people talk about Apache Shiro and indeed it features a very simple API and mechanism - that could potentially be application server independent.
Technical Questions:
Session: In my case I dont have an HTTP session - and from what I have understood Shiro at least needs some sort of SESSION ID that I need to pass around. Any nice way on injecting user credentials in my RMI/IIOP calls to the server with not polluting my business API?
Server side implementation: For the few resources I have gone through I think I can implement a Shiro DefaultSecurityManager by 'referencing it' from a Singleton Ejb 3.1 bean. Any other ideas?
Then I can easily create an interceptor and add it to my remote calls - so when a new call is going through my Remote EJB method - the Shiro Intereceptor to validate my user or check for specific rights.
Any comments/ tips / examples ?
Many thanks
From shiro, try to use a ServiceLocator pattern. The lookup of EJB is different between containers (JBoss, Netweaver, Weblogig, etc).
In Application Server, try to use the the container based constraints of security (#RolesAllowed, #PermitAll, #Deny...). JAAS will create the subject with principals of user, so just use the container authorization (#RolesAllowed, #PermitAll, #Deny...). Can be better when you migrate from one container to other.
As per the title, I am wondering what are some best practices for Web service user authentication and session management, mainly for backend implementation, especially using Java (J2EE).
Has anyone published anything on the subject? What kind of security considerations should one keep in mind when working with user authentication? What kind of design patterns are related? How should sessions be managed? What does a well-designed architecture look like?
Are there existing systems that could be used as good examples, or even bad examples?
As the Java EE specifications for web services actually consist in exposing a stateless session bean as a web service, you won't be able to implement session management without a "home-made" solution such as including a user token in each of your request.
Not specifically REST but we use same authentication mechanism for standard webservices as for any other web container request. Means send basic authentication data to backend. Over SSL. Never had any issues.