Security: Part II

[Dan Huskins]

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?

[Alastair Calderwood]

Hi,

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.

Alastair

[Dan Huskins]

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:

<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
</form>

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?

links:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security3.html

http://www.onjava.com/pub/a/onjava/2002/06/12/form.html

[Alastair Calderwood]

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.

What do you think?

Alastair

[Alastair Calderwood]

Sorry, I read the Sun design paper properly and now I understand what you mean. If you use CM authentication, you have to use CM self-registration, but this is platform-specific.

I think self-registration is still needed as it's a requirement for a web-based application, but that means that registration and authentication have to be coded, as you said.

I thought of these solutions:

1. write EJBs as above
2. use a J2EE pattern, e.g. Intercepting Filter which is for decorating processes with services like security - see

http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html

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

Any ideas?

[Dan Huskins]

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.

-d