Thanks for the post, we're seeing a lot more of these types of requirements.
The Forge HTML5 scaffolding does not do direct data-binding in the way that knockout does, at least not yet. At the moment it is simply using jquery to trigger the ajax calls to the server. We absolutely want to add this type of functionality though, although security processing is first on our list.
Speaking of security for HTML5 applications, I'd be curious about your specific requirements here? What type of security are you planning on using, and/or features? It would help us greatly to get some feedback!
Apologies if the following is vague (or repeats what you already know!) but its an attempt at describing the security requirements requested.
I tend to develop self service browser applications in the financial services industry.
This means that the security of any application is paramount. Authentication as a matter of course is two stage, the user is challanged for a username and password and then challenged for a piece of memorable data.
In the server side based application (which covers pretty much all of the existing well known frameworks from JSF through Grails to possibly even the Scala Play framework) that authentication results in a session (either a native Java Servlet session or some framework specific mechanism to manage the users access to the application). Usually the maintenance of that session is via cookies but can easily be maintained via URL rewriting.
My inclination currently is to do the latter via a servlet filter or a more native JAX-RS mechanism.
Other concerns are CSRF - The usecase for this from various discussions on the net suggests that the security restrictions of the JSON communication (same origin policy) mitigate against this and only require that the site hosting the web pages must also act as a proxy for the REST services if they are hosted on a different domain (not really a problem for a self service financial services app). Does this mean a equivalent of the s:token from Seam is no longer needed?
Generally I belong to the camp that pure JAAS is hard to fit into security requirements of a real world application and have had to implement bespoke role and user maintenance on numerous projects.
Hi Peter, no worries and thanks for the feedback.
We have been working to push forward security from the client to server side, currently doing R&D around this topic. Some concerns to bear in mind with regards to financial services is about security on the server side too.
User/password challenge + memorable data is a good approach. I know that HTTPS encrypts data before sending it out over the Internet, but should be great to add server and client side encryption, because HTTPS just cares about the transport. Why? Because sensitive data like these on the server could be compromised.
You might be careful about session hijacking issues when you trust on cookies to keep session and URL rewrite can allow end-user alter the submitted URL (for further information http://resources.infosecinstitute.com/owasp-top-10-tools-and-tactics/).
About RESTEasy is possible to use interceptors(http://docs.jboss.org/resteasy/2.0.0.GA/userguide/html_single/#Interceptors) or CDI interceptors to check your protected requests, the both alternatives are good.
I trying to figure out the relation between CSRF and JSON, but if I get it, the same can happen with XML payloads. We will never have a 100% guarantee that any controls will provide full protection, but maybe use a unique identifier to attach user request with a specific action and recreated for every request and action would prevent some issues. I'm not a Seam specialist but I think that check the appropriate authentication token is a good idea.
In Aerogear we have been doing some progress on the client side and the server side on DeltaSpike (http://wiki.apache.org/incubator/DeltaSpikeProposal) there's nothing set in stone actually, we appreciate feedback and suggestions.
I've been trying out the JEE 6 POH5 archetype in the latest milestone release of JBoss Tools. The implementation of the REST services is exceptionally clean and is a great advert for JEE 6 (the use of CDI to inject the EntityManager rather than using the legacy PersistenceManager annotation is nice to see).
The purpose of trying out the archetype was to look at converting the example to use knockout.js. This has been reasonably straightforward and once I clean it up I'll upload it to this thread.
And though I'm not so keen on the backbone.js View API the Model API cleanly abstracts the app.js code.
I may try and convert the example to backbone.js .
1 of 1 people found this helpful
I would recommend taking a look at the new JBoss Developer Framework http://www.jboss.org/jdf and specifically the client side implementation of the TicketMonster example https://github.com/jboss-jdf/ticket-monster
I'm hoping to contribute some minor improvements to that example when I have some free time but for the most part, I would recommend checking out their use of Backbone.
Seems to be just what I am after! Thanks for the links, backbone.js it is (but I still like databindings a la knockout.js!)
Is there any intention to enhance the "poh5 + JEE 6" archetype in JBoss Tools to generate a project that uses backbone.js?
My take on backbone.js views and knockout.js views ..... backbone.js views are like JSP's and knockout.js views are like JSF.
After some discussions with colleagues at work I realized there is another authorization usecase that becomes important in POH5 + REST apps namely field level permissions.
In a server side application world the server would be responsible for extracting data submitted by the web page prior to submitting it to the database.
This meant there was implicit (and actual) control over what fields on an entity a user could update when they submitted a request over HTTP.
REST apps probably initially will only offer control over what CRUD permissions a authenticated party has at entity level.
Is there any consideration being given to this as part of Apache Deltaspike?
It presents a considerable burden on organizations to implement field level permissions for services so I do have one suggestion which is that the field level permissions could be dynamically extracted from the HTML page definition at runtime i.e. parse the HTML page and extract a list of fields which are READ or READWRITE. This assume the server has access to the page definition (not always the case) and that the HTML page is in a parseable form (the backbone.js style templates aren't really, the knockout.js style ones more so although I still think it would be tricky).
Shane started the discussions about the authorization API and object level permissions over here (http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/DISCUSS-DELTASPIKE-79-Authorization-API-td4566205.html)
Some organizations write APIs like this https://www.owasp.org/index.php/Category:OWASP_Java_Project to field validation, just keep in mind the several trade-offs when you start with field validation on the server side, like decrease your performance. In the most cases, the combination of right validation on the client side and some changes on the server side are the way to go.