Sun's documentation draws a distinction between administrator setup and self-registration for adding users to a system for authentication. The former requires an admin to enter all of the details for each user, whereas the later allows a user to register himself. Sun says this about self-registration, which could correlate to external user's registering in Part II: "...self-registration mechanisms provided by J2EE platforms are platform-specific." Sun doesn't go into any detail about how to implement self-registration, but warns about putting SR into the application code.
If this is true, it seems like we're stuck between using a platform-specific self-registration system and writing code to process a form post and implementing security on our own. Any thoughts?
You could use container-managed authentication, so long as you stated in assumptions that FBN is going to use the same application server for a while (quite reasonable, but it might be seen as reducing maintainability).
If you want to do it yourself, one way is to put customer authentication for the web-based application in the business tier with a UserSignOnEJB, which checks in a user credentials database, as in PetStore. The travel agent's thick client would use a StaffSignOnEJB checking a staff database and then grant access to any customer's account. It makes sense to have different components for user and agent as apart from their different roles,factors like timeout period need to be different for each
Just some thoughts, I haven't started this part yet.
Thanks. But, this is what i'm a little unclear on. I think you mean container-managed authentication is the web-tier authentication-- HTTP Basic, Form, HTTPS Mutual, and HTTP Digest-- being configured within the <auth-method> of the deployment descriptor. If you use <auth-method>FORM</auth-method>, you must use these form variables:
And the corresponding username would still have to be configured by an admin. I suppose you could use a generic username for all external users, but wouldn't you still have to either write a specific EJB to handle new registering users or use some sort of proprietary self-registration system?
Thanks. Yes, container-managed authentication would be form-based. But I don't quite understand why you would need an admin to configure the username. You could write an EJB to handle user self-registration, and a JSP where the user could choose the username, provided it didn't already exist. Registration (unlike authentication) would not be container-managed, but does that mean that you need an admin?
If a user books through the travel agent, the agent's client app. could instruct another EJB to generate a user-name and password and (optionally) send these to the user's email address. The travel agent wouldn't need these to log on, but the user might need them if they later wanted to change the itinerary from the website.
3. specify container-managed auth/self-reg as architect, and leave it up to the developers to sort out the platform-specific problems - it wouldn't make you very popular in the real world but it's only an exam...
Each of those seems viable. It seems that we may be exposing a weakness in J2EE with handling self-registration-- stuck between coupling the solution with a vendor and customizing the solution with code.
Although I haven't really analyzed it yet, I'm thinking that a combination of standard filter strategy (intercepting filter) and a signon EJB might work. The I.F. approach would give you the ability to delimit the sections of the site which require login from those that don't-- and also accept different post types, which would allow users to bookmark sections of the site or email them.
I'll think through it, and post my thoughts later. Let me know where you get with it.