Skip to main content

JAAS and StatelessSession on GFv3.1

12 replies [Last post]
aszomor
Offline
Joined: 2009-08-06

Hi,

I wrote a custom JDBCLoginModule and a custom PrincipalImpl for test reason and put some debug lines them.
When I tested these programs I saw into server.log that all StatelessSession method call called a server side login, but I am logged only once!
Is it normal behaviour of the GFv3.1-b01-04_18_2010 ?

Attila.

CLIENT:
-------
InitialContext ic = new InitialContext();
// VIL !!! (Very Important Line) ??? or NOT I do not known why !!!
Object obj1 = ic.lookup("");
LoginContext lc = new LoginContext("helloRealm",ch);
System.out.println("Before Login !!!");
lc.login();
try {
sless = (StatelessSession)ic.lookup("enterprise.hello_stateless_ejb.StatelessSession");
for (int c=0; c<4; c++) {
System.out.println("StatelessSession bean says : " + sless.hello());
}
} finally {
lc.logout();
}

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aszomor
Offline
Joined: 2009-08-06

Dear Tim,

Do you known about from security team, were their attention to this thread, will they an answer for it?

I would like to store some extra information in the subject, because of the subject auto propagated in the cluster and between the layers eg. Bussiness Logic and the Domain (entities) and these informations needed for me everywhere.
We would like to develop a healtcare system and we always need to known about who is who recorded the data (an assistant), who is who diagnosed the patient (a doctor) and where happend it (a department). These information could be declared in the login process and these fixed until to logout and much more the intercept of their rights will be the real rights.
Thus if evry EJB call will destroy the subject and rebuild it by a background login mechanism our properetiary datas will be lost.

I put my full GFv3.1_M1 tests and their logs into this thread, please calling their attention to this thread again.

Thanks a lot, Attila.

aszomor
Offline
Joined: 2009-08-06

Dear Security Team,

I just reintroduce my question.

Attila.

kumarjayanti
Offline
Joined: 2003-12-10

I am not sure i understand your question. I am in the sec team. Can you file a bug with testcase, expected output and output that you are seeing.

aszomor
Offline
Joined: 2009-08-06

Dear Kumar,

As can you see we wrote a simple client as possible (one login, one lookup and call the sless.hello four times)
---------------------------------------------------------------------------------------------------------------------------------------------------------------
LoginContext loginContext = new LoginContext("default",callbackHandler);
System.out.println("Before Login !!!");
// -- 1
loginContext.login();
try {
__System.out.println("After Login !!!");
// ---- 2
__sless = (StatelessSession)initialContext.lookup("java:global/HelloApp/HelloApp-ejb/StatelessSessionBean");
__for (int c=0; c<4; c++) {
// --------- 3
____System.out.println("StatelessSession bean says : " + sless.hello());
__}
} finally {
__loginContext.logout();
}

on the server side a simple stateless EJB too (it has some logging information with System.out.println)
---------------------------------------------------------------------------------------------------------------------------------------------------
@Stateless public class StatelessSessionBean implements StatelessSession {
__@RolesAllowed("programmers")
__public String hello() {
____System.out.println("In HelloBean(Stateless)::hello()["+
______sessionContext.getCallerPrincipal().getClass().getName()+"]("+
______sessionContext.getCallerPrincipal().getName()+")");

____return "hello, world!\n";
__}
}

and we wrote and deployed a customLoginModule for logging reason, we put into the "authenticate" method this
System.out.println("AUTHENTICATE: <"+_currentRealm.getName()+">("+_username+")["+getPasswordChar().toString()+"]");

and we put into the "commit" method this
System.out.println("COMMIT: <"+_currentRealm.getName()+">("+_username+")["+getPasswordChar().toString()+"]");

When we deployed the server and started the client everything seems to be good from client side, we got the "StatelessSession bean says : hello, world!" four times we was happy.

But the server side we saw into the server.log that the CustomLoginModule was called four times, not once!!!

-----------------------------------------------------------------------------------------------------------------------------------
We attached our application, application's document, the server.log and the server configs.
The CustomLoginModule logging starting with "AUTHENTICATE" and ending with "CUSTOM PRINCIPAL".
The EJB logging start from "---\n""INTERCEPTOR" to "INTERCEPTOR""\n---".

You can see into the server.log the CustomLogin log before all EJB log, it is our problem.

Attila.

The client side log:
--------------------
2010.05.26. 10:29:01 com.sun.enterprise.transaction.JavaEETransactionManagerSimplified initDelegates
INFO: Using com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the delegate
Start Application Client
StatelessJavaClientAuthenticator programmer
StatelessJavaClientAuthenticator hello
Before Login !!!
NameCallback: (programmer)
PasswordCallback: (hello)
After Login !!!
@EJB sets the 'StatelessSession' to null !
NameCallback: (programmer)
PasswordCallback: (hello)
StatelessSession bean says : hello, world!
StatelessSession bean says : hello, world!
StatelessSession bean says : hello, world!
StatelessSession bean says : hello, world!
Stop Application Client

Server side log:
----------------
CUSTOM LOGIN LOG
[#|2010-05-26T10:28:58.657+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|AUTHENTICATE: (boss)[boss]|#]
[#|2010-05-26T10:28:58.664+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|COMMIT: (boss)[boss]|#]
[#|2010-05-26T10:28:58.665+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|CUSTOM PRINCIPAL: (boss)[boss]|#]

EJB LOG
[#|2010-05-26T10:28:58.721+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|-----------|#]
[#|2010-05-26T10:28:58.722+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|INTERCEPTOR|#]
[#|2010-05-26T10:28:58.722+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|Before: public java.lang.String enterprise.hello_stateless_ejb.StatelessSessionBean.hello()|#]
[#|2010-05-26T10:28:58.728+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|In HelloBean(Stateless)::hello()[org.glassfish.security.common.PrincipalImpl](boss)|#]
[#|2010-05-26T10:28:58.728+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|SUBJECT|#]
[#|2010-05-26T10:28:58.731+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|PRINCIPALS|#]
[#|2010-05-26T10:28:58.731+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|com.sun.enterprise.security.auth.login.CTJDBCLoginModuleUser|#]
[#|2010-05-26T10:28:58.732+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|SUPER|#]
[#|2010-05-26T10:28:58.732+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|boss|#]
[#|2010-05-26T10:28:58.732+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|SUPER (1)|#]
[#|2010-05-26T10:28:58.732+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|org.glassfish.security.common.Group|#]
[#|2010-05-26T10:28:58.733+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|PUBLIC_CREDENTIALS|#]
[#|2010-05-26T10:28:58.733+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|PRIVATE_CREDENTIALS|#]
[#|2010-05-26T10:28:58.734+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|com.sun.enterprise.security.auth.login.common.PasswordCredential|#]
[#|2010-05-26T10:28:58.734+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|After: public java.lang.String enterprise.hello_stateless_ejb.StatelessSessionBean.hello()|#]
[#|2010-05-26T10:28:58.734+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|INTERCEPTOR|#]
[#|2010-05-26T10:28:58.734+0200|INFO|glassfishv3.0|null|_ThreadID=28;_ThreadName=Thread-1;|-----------|#]

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

I looked at your Client and Server Code and the questions that you seem to have are the following :

1. Why called the CTJDBCLoginModule when I called the EJB, why not just when I called the LoginContext.login or ProgrammaticLogin.login.

Ans.) LoginContext.login() and ProgrammaticLogin.login() are local calls on the Client VM and have no remote counterparts on the server. IOW, no message is sent to the Server for these calls. Instead when the EJB is invoked at that time the Credentials from the Subject are carried over to the server side and the Server tries to determine each time whether the user is valid by authenticating against your CTJDBCLoginModule.

2. I guessed that the EJBSession is alive from Login to Logut and the custom attributes of a CustomPrincipal are modifiabled and usabled in that time.

No, unfortunately not. The kind of Session "Like" feeling you get on the client side from Login() to Logout() does not apply for the server.

Thanks.

aszomor
Offline
Joined: 2009-08-06

Dear Kumar,

These are very bad news for me, I hope these behaviors are temporally only.

1, Instead when the EJB is invoked at that time the Credentials from the Subject are carried over to the server side and the Server tries to determine each time whether the user is valid by authenticating against your CTJDBCLoginModule.
Ans) Our LoginModule will calling the Realm and if authentication succeeded will building the list of groups into the subject which are will be used by the server for the role mappings.
It could be a long time depend on Realm kind, but how many the possibility of revoke the grand from a logged in user (is it big)?

2, No, unfortunately not. The kind of Session "Like" feeling you get on the client side from Login() to Logout() does not apply for the server.
Ans) If I do not develop a web application (where a session is) just a Swing or RCP ACC client with Bussiness Logic server what can I do? I must generate an entity as a fake session and always use an id in communication for it like a PHP form hidden sessionid?

Thanks, Attila.

aszomor
Offline
Joined: 2009-08-06

Hi,

I tried it in GFv3.1_M1, but the result is same, all EJB call provoking a new Login.

Here is my test project and its log file.

Attila.

aszomor
Offline
Joined: 2009-08-06

Dear All,

First sorry my bad English, but I did not get any answer from the forum members and also from google searchs too.

I wrote a little test application from HelloAppDemo for testing the behaviour of ACC, the sources and logs are attached.

First I logged into server with LoginContext.login or ProgrammaticLogin.login and after I used the InitialContext.lookup and called the EJB four times and on the end I logged out from the server with LoginContext.logout or ProgrammaticLogin.logout.
As you can see in the glassfish-v3_1-b01-04_18_2010_server.log
AUTHENTICATE: (boss)[boss]
COMMIT: (boss)[boss]
CUSTOM PRINCIPAL: (boss)[boss]
these messages which are echoed from CTJDBCLoginModule.java always appear before
-----------
INTERCEPTOR
...
INTERCEPTOR
-----------
these messages which are echoed from StatelessInterceptor.java.

Why called the CTJDBCLoginModule when I called the EJB, why not just when I called the LoginContext.login or ProgrammaticLogin.login.
I guessed that the EJBSession is alive from Login to Logut and the custom attributes of a CustomPrincipal are modifiabled and usabled in that time.

Please give me a sort answer from behaviour of GlassFish and if I would like to use custom attributes of a Principal how do I that.

Thanks, Attila Szomor from Hungary.

tjquinn
Offline
Joined: 2005-03-30

The security team will know more about this, but when a client provides the username and password they are held in the client security code until the first time a client accesses something on the server that requires authentication. Only then is any authentication actually performed.

So in your example when your client calls the EJB that is when the authentication actually occurs.

- Tim

aszomor
Offline
Joined: 2009-08-06

Dear Tim,

In the first thanks your answer.

If you can please send my question and HelloAppACC.zip (22.8 K) to the security team. They can send me an answer to my private e-mail: attila@szomor.hu.

I tried this program on JBoss AS and there worked normally the CTJDBCLoginModule was called only once by login and the CustomPrincipal was usable in all EJB call.

Thanks a lot, Attila.

tjquinn
Offline
Joined: 2005-03-30

I have sent a separate message to the security folks calling their attention to this thread.

- Tim

aszomor
Offline
Joined: 2009-08-06

Dear Tim,

Thanks a lot!

I saw the GFv3.1 M1 was issued, I will try this whiit that too and I will report the result.

Attila.