The following is my project requirement.
1.Project wont maintain a separate user table, the users of our project database server itself will be used a user for our application.
2.For Authentication i am following this way----When user submits username and password a separate Connection object is created, if Connection object is not null then user is valid else he is not a valid user.
So as per above rules as of now i tried to validate a valid user using a login html form.
What if i want to automate Authentication process with Server supplied Authentication mechanisms like Tomcat by using Basic Authentication or Digest Authentication.
For these mechanisms 1st option is i need to use xml files and enter manually usernames and passwords of all users and other option could be using a JDBC Realm and configure usertables. But in my current project i shouldn't maintain user tables at database.
So how can i authenticate a user using Server supplied Authentication mechanisms without maintaining user details in a table nor with entering xml entries instead using direct database users as valid users for application.
Is it possible technically. Thanks in Advance for your replies.
The J2EE container security Realm architecture allows for 3 types of data: user id, role id and password, where there is a 1-1 relationship between userid and password and a many-many relationship between user ID and roles. Realms do not support retrieval of this information; instead, the Realm supports methods whereby the system can inquire if a value exists, but not what values exist. That prevents rogue processes from enumerating secure resources and dumping them.
If you desire additional user information above and beyond what the authentication and authorization system (Realm) provides, you can reliably use the userID from the HttpServletRequest as a key into whatever mechanisms you code into the application itself. Typically, these mechanisms would access a database or LDAP server, but it's up to you.
To use an XML file to maintain the Realm credentials, you must plug in a Realm that reads and uses the data in that XML file. The original implementation was the MemoryRealm, but it suffered from the drawback that any changes to the XML would not be dynamically applied - you had to stop and restart Tomcat.
Typically, an XML-based Realm is useful for testing, but production systems generally use LDAP or database Realms. LDAP works well for in-house users, especially in Windows shops, where Active Directory already does a lot of that work. For external webapps, where not all users are logged into the LAN, database Realms are more common.
Tomcat 6 also introduced a special Realm that concatenates multiple Realms, so that for example, internal users would be in Active Directory and external users would be in a database.
Customer surveys are for companies who didn't pay proper attention to begin with.