A few thoughts here: In general, what you're laying out here involves too much logic in the Listener.
If the data on the two LDAP servers doesn't change, why create new instances of those components for each authentication attempt? I wouldn't want my Listeners to have to pass anything related to the LDAP server into the SecurityManager. Nothing outside the SecurityManager should even know that the authentication involves an LDAP server. If SecurityManager is a service layer component, shouldn't it be a Singleton? If so, this should not be instantiated on every authentication request. I would not have the Listener need to know that it must call authenticateUser() and authorizeUser(). I would just have some generic method like validateLogin(), and internally the SecurityManager handles hitting the LDAP servers and then hitting the database for the user info (probaby via a User service). Nothing outside the SecurityManger should know that there is a two step process involved (hitting LDAP and then hitting the database). I would not have the Listener be responsible for getting back a User object and pushing it into the session. The Listener shouldn't know anything about the session scope or that it is even being used. I'd have the SecurityManager push the User object into the session via a session facade (probably what you're calling SessionManager). Hope this helps. Brian On 10/28/07, Leigh <[EMAIL PROTECTED]> wrote: > > > Hi, > > I'm currently experimenting with my first Mach II app. I have outlined > the login scenario below, along with what I think is the preferred > implementation option. If anyone can offer any suggestions/issues with > what I have presented it would be greatly appreciated! > > Thanks for any help in advanced! > Leigh > .......... > > Scenario: > > - After a user submits username/password via login form, have to > Authenticate them by seeing if they are in either one of two ldap > servers. If found (authenticated), I extract their user id_number, > name, email. > > - Next, I need to then Authorise the user against my system's > database using the username/id_number (taken from ldap authentication/ > lookup) and get some other info about the user from my db. > Authorisation possabilities are - they might not have access/ > authorisation (username/id_number not in system database), be a normal > user (ie username_number in the system database) or be an > administrator (indicated by a flag in the database if user record > found). > > Out of my options below, I think 1 is the best. Logging in always > requires authentication/authorisation, therefore does not need > separate calls from the listener (like option 2) - I'm not too sure > though about securityManager being composed of a system_user object - > is this ok?? I don't like option 3 as I don't think the system_user > object needs to be aware if it isAuthenticated/isAuthorised, however > isLoggedIn in could be useful at some point. > > Finally, I need to read the user info from my ldap object into the > system_user object. To do this, I currently have a method > readLDAPUserAuthDetails() as a part of the securityManager, that calls > Get methods for the ldap object and Set methods from the system_user > object. This means then that I could reuse the ldap object in another > app, because it doesn't rely on understanding the set methods of the > system_user object - I think this is ok because even though the > securityManager has to work with the get/set methods of each object, > being the business model, it does not have to be portable. > > Option 1: > Create a loginListener with method processLogin(). The logic of this > as follows: > > 1. Create 2 instances of an ldap object with details of the servers to > lookup the user > 2. Create an instance of a securityManager. > 3. Call the securityManager.login() method, passing in username, > password and the 2 ldap objects in a structure > 4. The securityManager.login method contains logic to process the > authorisation/authentication - at any point, if there is an issue, > return false. > 5. The securityManager is composed of a system_user object, which it > populates appropriate attributes based on the logic in 4. and can be > read by the loginListener to pass to the session manager. > > > Option 2: > Create a loginListener with method processLogin(). The logic of this > as follows: > > 1. Create 2 instances of an ldap object with details of the servers to > lookup the user > 2. Create an instance of a securityManager. > 3. Call the securityManager.ldapAuthenticateUser() method, passing in > username, password and the 2 ldap objects in a structure > 4. The securityManager is composed of a system_user object, which it > populates appropriate attributes from the ldap lookup. > 5. If authenticated, call the securityManager.authoriseUser() method, > which gets the id_number/username out of its system_user object and > reads my system db for the other required details. > 6. Call a session manager object and pass to it > securityManager.getSystemUser() so that a session can be created. > > > Option 3: > Create a loginListener with method processLogin(). The logic of this > as follows: > > Same as option 2 (points 1,2 & 3), except login() returns a > system_user object, which has attributes of isAuthenticated and > isAuthorised > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
