Welcome to the JavaRanch, Rajesh!
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.