# start a struts based web apliation.
# create a LoginValidateAction that receives all requests.
# The LoginValidateAction that checks login Id and password against valuses stored in a RDBMS, and retuns what roles the user is authorized.
Yes I also understood this way, up to here.
but in following :
# The LoginValidateAction creates an instance java.security.Principal object(s) and stores the object in the users session.
# Can this be a custom security principal? ex:MyCompanyPrincipal implements java.security.Principal
I don't think it can be a custom security principal the way you describe it because the Principal object is created internally by the container. We just specify the user in Properties in client side application and on server side its in xml file.
# Let's say in the above case. the user validates to the role "ReadOnly", and "Auditor".
# for every jndi lookup I could - Seems like an annoying way to code a large J2EE app.
Context ctx = getIntialContext(props);
Thing resource = (Thing)ctx.lookup(java:env/......);
The simpler way for (like in your struts application)as I understood might be to write a single class for jndi lookup for all beans that you are going to use in your application and provide accessor "get methods" for the home interface to other Action/ActionForm classes, rather than providing jndi lookup in each Action/ActionForm class.
# Create a ServiceLocator ojbect for each user. It would have access to the security principle impplementation. Then as the user want a reference to a JNDI factory. It could call the lookup with the proper security role.
As,I don't think you need to create this Principal object. But you can create this ServiceLocator object as I said as a single class for jndi lookup for each bean. So far the question of each user is concerned I think perhaps you are getting confused between user and role. Each user will be a part of a role that we specify in xml file and you will be getting each user's role from database on user's login. This role you specify in client program in Properties. Since a role represents a group of users , there won't be many lookup codes for each bean for each role.