This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I am writing an application that requires user registration and the login details will be saved in a database (MySQL). In a realworld example, where is the username kept in the db? i.e. is it best to use the existing user table provided by mysql? or do I need to create a new table and store the usernames in there? is the predefined user table from MySQL, reserved for admin users? Also the password. How and what is the best way of storing passwords to the database? Are there any books which show "real-world" examples of such thing? Please help as this is the first time I'm doing this thing and I have no idea!!??
The usernames and passwords you propose storing are from a database perspective merely application data; you don't want to create a database account for each user, you want to create a single database account for your application, and store application data (such as application username and password) using the one account, which you use to get your database connections.
In the real world, authentication data is sometimes held in an external LDAP store, such as Open LDAP, Active Directory, Novell or NDS, in order to validate user credentials based on a username-password combination or a digital certificate.
I've also worked on enterprise apps where we used WebLogic Server's embedded LDAP server to persist all of its information about users, groups, policies, roles and user credentials.
So, if I create a username and password for the application and only use that to connect to the database and then just have the username and passwords for users as normal application data. ofcourse the password will be encrypted. then the verification will be done via comaring the actual inputs against what is stored in the database, when the applications is already logged in to the database. Ok, I think I understood this part. But what about the LDAP? how does this work? Are there any examples that specifically illustrate this procedure? I've tried searching the net, but so far haven't been satisfied with my findings.
Any links or explanations will be greatly appreciated!
My opinion: forget about LDAP for now and go with the database solution.
Background: I just finished a project converting our LDAP directory for user information into an SQL database. The people who designed the system put the user information into an LDAP for whatever reasons they had; but then we wanted other information in there, such as their customer number and what applications they had access to and so on. Everything in the directory was a string, so it was easy to input invalid data. The tools for maintaining the information were user-unfriendly. To ask questions like "How many users do we have from chain X" required learning a new query language, about which it's hard to find any information, and we're already overloaded with learning new languages and new versions of old languages. It was just dysfunctional.