Ernestas Vaiciukevičius

In the previous post, a sample web application was created, which authenticated user using OpenId and retrieved some personal data from user's Google account.

Next step is to allow users to login to our web application using the retrieved identity. Unfortunately API provided by standard J2EE does not allow detailed control over the authentication process.

Servlet 3.0 specification introduced some new security related API (authenticate, login), which could force authorization and login user programmatically by login and password, but it's still not enough.

If our web application would support just single authentication method, it could be implemented using this new API together with some corresponding security configuration backed by JDBC, JAAS or whatever else app server supports - after successfull OAuth/OpenID negotiation, we could simply programmatically call the login() method with some fake password (neither OAuth nor OpenID would not give users real external account password of course). But that would require mandatory external account from our users, which is typically not what is required.

What if we want to provide external authentication as an additional option without depending entirely on external system and still allowing users to register and use usual login/password authentication ?

Things are getting more complicated because if we for example allow FORMS authentication to the users - we obviously cannot use any fake passwords to authenticate users programmatically via OAuth/OpenID. And it turns out that there is no way to implement such scenario in portable J2EE way (perhaps someone would still have any ideas ?  Any thoughts are welcome.)

So the implementation would depend on specific application server and would be tightly coupled to server's authentication handling machinery.

To abstract this non-portable part and localize it in one place so that different implementations could be substituted, lets write some abstraction API.

Full story »

These days for any internet user it may be very difficult to remember numerous different logins and passwords to different sites he has accounts at. However almost every internet user uses at least one public email service or is registered on some social networks.

Working SSO (single sign on) sulutions would really make user experience on the internet much better. As big players competing for the users are not likely to adopt this approach anytime soon, many smaller sites could benefit from users having accounts on those popular systems.

For example they could login the users right away or at least pre-fill the registration forms using personal data retrieved from users external systems accounts.

Moreover open standards for such authentication/authorization methods are already in place and they are being adopted by big players. These standards are OpenId and OAuth. They potentially could also be used in the enterprise environment with many different web systems as yet another option for implementing SSO.

I decided to explore possibilities of using them in a sample J2EE web application.

First step for this is to actually delegate user authorization to external system and get some user's data. For this purpose I've written a pair of servlets implementing authorization by OpenID or Facebook API (which uses OAuth).

Full story »

Link: http://jsoup.org/

This tiny HTML parser helps you to clean potentially unsafe HTML code (comments and other rich text provided by online users)  to be put on your site without worries about XSS (cross site scipting): http://jsoup.org/.

It can easily use it in a JSF Converter or Validator with just a few lines of code and attach to your rich-text editor components. This way you could prevent malicious code to be processed further or just "clean" it and use just "safe" part.

Usage example:

String unsafe =
"<p><a href='http://example.com/' onclick='stealCookies()'>Link</a></p>";
String safe = Jsoup.clean(unsafe, Whitelist.basic());
// now: <p><a href="http://example.com/" rel="nofollow">Link</a></p>

Just an update of the utility code described in the previous post.

Now correcty commits transaction in cases where response is rendered earlier in JSF lifecycle.

The code is here:  EVServletPersistenceManager v0.2

In a Jetty+Facelets+ICEFaces+EclipseLinkJPA  environment, there's no standard and easy way to manage EntityManager lifecycle without having to create/destroy it in every method communicating with database. That's not very convenient.

Google search on this problem didn't found much, altough it found this link: http://javanotepad.blogspot.com/2007/08/managing-jpa-entitymanager-lifecycle.html.

Based on that idea I implemented similar servlet context listener, but bound EntityManager to ServletRequest instead of binding it to a thread. This approach could work in Servlet/JSP-only (perhaps JSF too), but with ICEFaces it didn't work (the original approach, entitymanager per thread, most likely wouldn't work too) becouse of ICEFaces request processing specifics  (ServletRequestListener didn't got notified for every "request", the same ServletRequest was used for several "requests", etc.). To solve this, I wrote JSF phase listener, which injects EntityManager as request attribute for every JSF request and cleans it up after request processing.

So here is resulting code (sources are in the same .jar):

EVServletPersistenceManager-all.jar

Full story »