Drivel design?

[rollatwork]

Question: Is it largely non-sensical and unadvisable to have a custom login module that makes a call to an EJB to perform its authentication?

On the server-side, we've used fairly simple custom login modules in the past with success. Currently we're re-writing some modules and want to leverage existing logic from our business interfaces, in this case our Session beans. Previously the login modules would encapsulate all the business logic.

From a design pov does it make sense to have the login module call an EJB (which I'd assume would have to be un-secured...??) or should this be mutually exclusive from our business objects? If it does make sense, are there best practices for how these authentication specific EJBs should be deployed?

We'll likely want to use a similar scenario on the client side that would invoke some EJB rather than just caching the principal via the ClientSideLoginModule. We'd probably want to extend this to actually perform some authentication on the client in addition to storing the principal for later EJB invocation.

Please deposit 2 cents here,
Roll

[jamesstrachan]

Roll,

The first thing to release is that, once you apply security, ALL EJB method calls must be accompanied by principal and credentials. Your client (assuming that it is a heavy client) has to store principal and credentials in the client context and supply these with every call.

You could write an unsecured module that tests and validates credentials independently but it doesn't gain you very much.

It's simpler to have an empty method on a session bean which is called to test principal and credentials from the login screen as soon as the user has entered them.

I can dig out some sample code if this is of interest.

James