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.

RESTful webservices are meant to be stateless so as I understand it the only way to secure these services is either to require the client ( via some javascript code) to obtain a session key object and send it back to the server on every request or to break the REST requirement and allow the use of a cookie (or URL rewiriting) to establish a session to track the user with that session being shared by each and every participating pseudo RESTful web service.

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.

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.

But in the process of converting the example to knockout.js it's highlighted to me what another much touted javascript library has to offer, namely backbone.js . Even though knockout.js made the html page data binding more intuitive, pretty much all of the app.js code is still needed with the ugly use of $.ajax or $.getJSON calls. After doing a search for 'javascript client api JAX-RS I came across:

http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started/

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 .

There is another project that tries to combine knockout.js with backbone.js but I'm not sure how much traction it has but it seems to take the best bits from both javascript libraries (i.e. the Model definition of backbone.js plus the bindings and autoupdate features of knockout.js)

http://kmalakoff.github.com/knockback/

Cheers,

Peter.

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?

Presumably the ultimate goal of this archetype is to allow user to either pick some database datables or JPA objects and generate different javascript and java files, and if you have existing JAX-RS services then I guess it would just generate the javascript stuff.

My take on backbone.js views and knockout.js views ..... backbone.js views are like JSP's and knockout.js views are like JSF.

Cheers,

Peter.

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).