confused about security constraints and loginning in

[peter cooke]

Ok I am really confused and looking for a good explanation. At this point any explanation will do.

I have a web app. I want to have a login that validate login id and password, as stored in a DB2 table on an AS400. Then generate all the standard J2EE security stuff for me to use role base security to show conent and buisness methods.

I have much confusion about what these security objects are other than vague terms like "realm", "prinicpal", "role". I know enough about the web.xml and ejb-jar.xml to say that class and metods have a constraint and must be executed by some role.

How do I create USERS and ROLES that my webapp then can leverage???
In JSP/Servlet container, will putting an instance of Prinicple in the session start the ball rolling???

[Damanjit Kaur]

Hi

I was just reading about roles, principals in EJB book. It specifies principal is a java.security.Principal object used to gain access to Beans and their methods. We mention it in client program with following code :

properties.put(Context.SECURITY_PRINCIPAL,username);
properties.put(Context.SECURITY_CREDENTIALS,userpassword);

and pass on this properties object to InitialContext for Bean jndi lookup.

The username is principal which is specifed as role name in deployment descriptors file i.e. ejb-jar.xml file under <assembly-descriptor > tag. The role denotes a group where group can differentiated according to security constraints that we specify for each group. Here is the example that I have in book:

<security-role>
<description>
Role is allowed to execute any method on a bean.
</description>
<role-name>
Administrator
</role-name>
</security-role>

<security-role>
<description>
Role is allowed to execute only one method on a bean.
</description>
<role-name>
ReadOnly
</role-name>
</security-role>

and then method permissions are given as follows.

<method-permission>
<role-name>Administrator</role-name>
<method>
<ejb-name>CabinEJB</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>

<method-permission>
<role-name>ReadOnly</role-name>
<method>
<ejb-name>CabinEJB</ejb-name>
<method-name>getName</method-name>
</method>
</method-permission>

Now when client invokes some method on a bean, his principal is checked to see if its a member of a role mapped to that method. and when the bean whose method is invoked in turn inokes some method on another Bean, the principal info of first bean is passed on to this next bean which again check the access for the principal passed. This feature can be overridden by using run-As thru which one can specify different principal and not same as is passed on from calling bean. e.g.

<enterprise-beans>
....
<entity>
<ejb-name>EmployeeService</ejb-name>
...
<security-identity>
<run-as>
<role-name>Administrator</role-name>
</run-as>
</security-identity>
...
</entity>

....
</enterprise-beans>
<assembly-descriptor>
<security-role>
<role-name>Administrator</role-name>
</security-role>
<security-role>
<role-name>JimSmith</role-name>
</security-role>
...
<method-permission>
<role-name>JimSmith</role-name>
<method>
<ejb-name>CabinEJB</ejb-name>
<method-name>Create</method-name>
</method>
</method-permission>
...
</assembly-descriptor>

In this e.g. it specifies that JimSmith can only create bean using Create method on CabinEJB but if this bean has to call methods on another Bean EmployeeService then the principal for that bean will be Administrator and thus have all access as assigned to Administrator role.


Besides this, there is also another option called <unchecked/> which specifies that methods specifed following it can be called by anyone.

<method-permission>
<unchecked/>
<method>
<ejb-name>CabinEJB</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>CustomerEJB</ejb-name>
<method-name>Create</method-name>
</method>
</method-permission>

I don't know anything about realm.

[peter cooke]

So If what I am hearing is correct. I should be able to:

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.

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

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.

properties.put(Context.SECURITY_PRINCIPAL,username);
.....
Context ctx = getIntialContext(props);
Thing resource = (Thing)ctx.lookup(java:env/......);

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.

Learning this is making me feel like: "I am relearning how to write sendmail.cf files from scratch".







[ December 23, 2004: Message edited by: peter cooke ]
[ December 23, 2004: Message edited by: peter cooke ]

[Damanjit Kaur]

# 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.
properties.put(Context.SECURITY_PRINCIPAL,username);
.....
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.