How to apply the Pattern concept to design a login process?


General J2EE: How to apply the Pattern concept to design a login process?

  1. Hi all,
      I am a J2EE pattern novice. I have read some introduction articles. In my unstanding, patterns a proven solution to a recurring design problem. So, does it mean that if now I am going to design an internet shopping system, there are some design patterns for me to follow?
      On the other hands, when designing the login process of that system (use JSP/Servlet as View, EJB as Business Logic, and access the user login data by DAO....), then how to apply the concept of Pattern on it?? or there are some patterns talking about a login process?? Could anyone tell me how to find those examples?
      Finally, I afraid that if I was misunstanding the concept of pattern design and ask those stupid questions. I hope that someone can kindly to tell me the answers .
      Thanks very much.


  2. I think it is best to delegate authenticaton and authorization to the appserver rather than taking up things in your own hands. restrict access to you'r checkout pages in the deployment descripto, if you are using an MVC model with a Servlet request dispatcher (command model), simply have another alias of the servlet handle the checkout portion. this way you donot have to write a authentication and authorzation logic in your code.
  3. Hi Keith,

    You are partially correct in that design patterns are meant to solve common design problems that arise - but not on the scale you are thinking. Generally speaking, the patterns, if taken individually, would not necessarily apply to "an internet shopping system" as a whole, or even as a login process as a whole. Instead, the design patterns would help you in certain aspects of designing your system...which would, in turn, have an impact on the overall system design.

    Two different shopping cart systems, for example, could employ vastly different design patterns and practices. It all depends on what the system requires. Just as a basic example, a Java Bean is a design pattern that you could apply when designing the login process of your application. While a Java Bean is not a design pattern specific to a "login process", you could still apply it if it makes sense to your needs. On the other hand, you might find that it's more appropriate for your system to have a single LoginManager to handle all login requests in which case you could consider the Singleton and Factory patterns.

    As you break down your application into functional areas/components and what have you, you'll come across areas where design patterns will be applicable.

    I know this wasn't a cut and dry straight answer, but I hope it gives you an idea of how patterns come into play during design.

    Good luck.

  4. JAAS would the answer for you.
  5. Thanks all of you, your messages are helpful to me!

    One more question, what is the pros and cons if delegate authenticaton and authorization to the app server? Is it depended on the system's size or the performence of the app server? What the J2EE systems in the market usually use, by the app server's user management system or implemented individually?
    Thanks for any opinions.
  6. The pros:

    - You save writing a lot of code
    - Security is declarative
    - lends itself to single sign-on... all applications can potentialluse the same authenticaltion realm

    The cons:
    A migration to another appserver might not be very clean if the other app server doesnot support the previously used realm... but this issue can easly be solved ince most application servers provide some way of introducing custom realms for use with authentication (JAAS or otherwise)