Avoiding Principal and credential check for unchecked method

[jburugupalli]

Hi All,

I have athe following scenario were one should login and then proceed for a client. So i declared the login() method of the respective facade bean as unchecked. My problem is i want to make only this login method unsecure and others secure. From my login dialog i borrowed the username and password and set them to the LoginContext as follows

AppCallbackHandler tAppCallbackHandler = new AppCallbackHandler
(iUserName, Password.toCharArray());
LoginContext lc = new LoginContext("WorkClient", tAppCallbackHandler);

every thing works fine when the username passwrod is correct, but when the password is wrong then it gives me authentication exception from the Login module even though i had set the method login() unchecked . I am sending u part of ejb-jar.xml for the facade bean. I even added unauthenticated-principal and unauthenticatedidentity params.
Please help me if it is possible to do in this way.

thanks jani



<method-permission>
<role-name>ClientCall</role-name>

<ejb-name>SessionFacade</ejb-name>
<method-name>*</method-name>

</method-permission>
<method-permission>


<ejb-name>SessionFacade</ejb-name>
<method-name>create</method-name>

</method-permission>
<method-permission>


<ejb-name>SessionFacade</ejb-name>
<method-name>login</method-name>

</method-permission>

[starksm64]

I don't understand what the problem is. Doing a LoginContext.login will of course fail if the password is invalid. Describe the method flow more completely along with the behavior you expect and the exception that is not expected.

[jburugupalli]

Hi scott,
- As u said i do call the login() method in the client before i call any method on the server. I thought it is used for the next calls made by the client for which there is a method permission described
-But my first call form the Client is a SessionFacade.login(usrname, pwd) which has a method permission
So in this case i dont want any validation of my principal and credentail as it is a login method and this method will do the login mechanism and deliver an error message if login fails and if login is successful then the next call from the client will be on a methos which has some permission with a role set.

I hope its clear and i as u said i will look into the point LoginContext.login() method call. I will try to avoid this call for the first method call made by the client and then call this method in the second case.

And by the way thanks for the docs u provided on jaas-HOTTO as usual i did not under stand it when i read for the first time but got the points on the second time and my data base login module works fine with only USER table and a hard coded single ROLE for all the users withour having a table for roles in the database.

Please mail me again if u did not get my point which i explained.

By the time i wrote this mail i tested my changes and it seems to be working .

For the first time facade.login() call i did not perform the LoginContext.login(). But then if this call was successfull then i am calling the LoginContext.login() method and then invoke the other methods. It is working fine.

regards
jani

[starksm64]

The the login method needs to be declared as unchecked in the ejb-jar.xml descriptor. I can't see your fragment because it was not encoding in code block using the [ code ] ... [ / code ] ( no spaces in practise ).

However, if I understand what your doing, the behavior you see is expected because doing a JAAS login on the client establishes the caller identity and this is validated even on unchecked methods. Unchecked simply means that no particular role is needed, the caller still has to be authenticated.

You would have to make the login call before you did the JAAS login in order for the unchecked permission along with the unauthenticatedIdentity to work as expected.

[jburugupalli]

Hi Scott,

Can you tell me the reason why the property
"org.jboss.security.SecurityAssociation.ThreadLocal" its always default false.

and the class comment of SecurityAssociation class explains this

When the property is false or does not exist, the thread local storage object
is of type java.lang.InheritableThreadLocal, and any threads spawned by the
current thread will inherit the security information of the current thread.
Subseqent changes to the current thread's security information are NOT
propagated to any previously spawned child threads.

When the server property is false, security information is maintained in
class variables which makes the information available to all threads within
the current VM.

I have a case were i invoke a SessionBean from a client using the InitialContext with the LoginInContext and that work fine. And from a method within the SessionBean i invoke another EntityBean with again an intial context and no LoginContext. And i also have a senario were a servlet invokes the sessionbean with IntialContext and no LoginModule. After starting JBoss when i call this servlet the Session bean is invoked with unauthenticated Identity and thats fine. But after making a client call then the servlet call , the servlet is also having a principal and credential same as the client has. I dont understand why they are shared by both calls even thouhg i am using seprarate look ups in both cases. I guess these principal and credential are shared for the whole thread as getinstance mechanism and i dont want this functionality..

please help meovercome this ...or point out if i am doing any thing wrong

regards
jani

[jburugupalli]

HI Scott,

I have found the way to do it. I should use the ClientLoginModule for the clients calling EJBS with in the VM from the login-config.xml. and then i can set the multi-threaded option to true which inturn sets the SecurityAssociation.setServer() thats fine.

Client -----uses ClientLoginModule from the client auth.conf file--------> SessionBean --------uses ClientLoginModule from the client-login ----------> EntityBean

From client --> SessionBean i pass user1 and pwd1 and validate using my own LoginModule

In same call the SessionBean ----> Entity bean with usr2 and pwd2 and again validates it with my own loginModule

So when i invoke the client it fine it uses uer1 pwd1 but the Session---> entity call also uses usr1 and pwd1 instead of usr2 and pwd2.

Any Idea why ?? or is this process totally wrong. Because All my Client to Session calls are from clients and the Session to Entity calls are within intry VM.
Can you help me

regards
jani