Posted by Joseph Nusairat
Tue, 20 Feb 2007 05:00:00 GMT
A few days ago, I blogged complaining how in Seam 1.1.5 in order to create your authentication class you had to create a method with 3 parameters: username, password, and a mutable set of roles. Well, this weekend I downloaded Seam 1.1.6 and much to my surprise they've changed it. In 1.1.6 you inject an Identity object into your POJO instead. This identity object contains the username, password, and set of roles. I'd like to think my blog had something to do with that, but I highly doubt it ;-) I just wanted to add this correction and send a kudos to the Seam team for changing it. Of course your authenticate method still has to return a boolean ... but that is much more acceptable behaviour.
Posted in Java, Seam, JBoss | Tags Seam, Security | no comments | no trackbacks
Posted by Joseph Nusairat
Mon, 05 Feb 2007 05:00:00 GMT
I've recently downloaded the latest Seam distribution (1.1.5). 1.1.5 is when Seam adds Security, and I wanted to update the source code for my book, Beginning JBoss Seam, accordingly.
For the most part I’ve been happy with their security implementation; however, there is one thing that really bugged me. In previous “development” releases they had the security class extend an interface. However, that went against the Seam paradigm of using POJOs everywhere. So now they made the security is implemented as a POJO. Now that in itself isn’t bad, but in my opinion their implementation is questionable.
The way Seam implemented it is there is a specific class for login in and out, passing in username and passwords etc. In order to authenticate using it, you are required to create a POJO has a method like boolean (String username, String password, Set roles)
You can name it anything you want. But the parameter and return has to be in that format. Furthermore the method takes in a username and password, and then sets the roles that are assigned to it. So now you are forcing the parameter “roles” to be a mutable object, something I try to avoid at all costs.
Fair enough they had a hard time implementing a solution. But if you are going to the extent to make the method EXTREMELY specific go ahead and just have it implement an interface. Thats what they are there for. A POJO while a great concept, is not a 100% solution. And in general POJOs are great for business services or presentation tier services that could be accessed in a non-specific manner. An authentication mechanism is not that way. Authentications almost always are very specific. you have a username, password and then are going to return authentication credentials. I understand what they were trying to accomplish but sometimes I think people are soo desperate to make everything a POJO, even items that shouldn’t be.
Final thought, I started this blog "Abusing POJOs?" with a question mark, the reason being to ask yourself is this really abuse or is this the way it should be.
Posted in Java, Seam, JBoss | Tags Seam, Security | no comments | no trackbacks
