Tuesday, November 10, 2009

Using the built in login versus ProgrammaticLogin

Yeah, I figure I'd cover a bit of Glassfish and JavaEE nuances. Today's gem is logging in.

When you think of logging into something you may have a sudden urge to think, "Yeah it's just a database with users and passwords stored in it."

To an extent you are correct. The broad 10,000 feet view of logging in is that you present something and that something proves you are who you say you are.  In some cases it is a password, some cases it may be a USB stick, and in some cases it may be something on you like your thumbprint.  However, the fun thing about being a programmer is that you not only get to deal with the details of where, what, and how idenities are matched with proof, you also deal with the way it is prosented to the user, interfaced with that presentation, handled during transport, how to transport, and so forth.  Basically you'll leave wondering how the API actually helped you.

But I'm getting ahead of myself, short end is that no matter what framework you use; be ready to do a bit of leg work when it comes to logging people in.

Now on to the topic at hand.  In JavaEE there is a set way of how to handle logging in to an AS.  This method is known as JAAS (say it with me: Jazz).  Without going into what that means (you can safely assume that the J stands for Java) JAAS is the standard built-in method for logging into an AS.  Now JAAS is great and all but it was mostly intended for web based applications, so if you are doing a lot of web based apps then just sticking with the default JAAS won't do you wrong.

Therein is the problem, if you are doing Client Application programming (thick clients) you may seek to have a bit more control over the login process.  JAAS is an okay solution, and you can work around some of it's limitations, but after a point you're just boiler plating and you need to stop.  One thing about JAAS is that it is specific to the Application Control Container (ACC), that's not to say the code isn't cross platform, it means that the ACC handles login, not you, you have to keep poking at the ACC for information about the current state of the login.  This simplifies things at an amazing rate.  You can have a databased back login module in less than five minutes.  In fact you'll spend most of your time with SQL.  The problem is things like making sure the person provides a valid login add complexity because the ACC will toss an Exception at you and your client will receive a very cryptic error message about RMI-IIOP.

This is all because when something bad happens you can't trap the ACC (that's a good thing security-wise) and therefore authentcation errors blow up your client.  You have to write EJBs that force the system to log you in and then before actually using that login check to make sure it is okay.  This can add a bit of overhead in Client Applications...

Enter ProgrammaticLogin.  The purpose is pretty stright forward, handle logins programmatically.  Two problems with this approach, this will lock your code (once you start coding for ProgrammaticLogin you are locked into Glassfish with you code sans a major rewrite); second, you must handle everything about logging in yourself.  ProgrammaticLogin is lock-in for every platform, yes that's right, everyone has a ProgrammaticLogin (JBoss, Oracle, IBM, etc...), every single one of them makes it look the same (takes two to four parameters, passes information on to EJBs, etc...) but they all do it very differently per AS platform.  Judging by history, this makes it a good candidate for inclusion in the next version of JavaEE (???).

I guess I'll cover a bit about logging into an AS next time, I'll cover JAAS first.
Post a Comment