(WS 6.1) fat client wants to use authentification obtained with EJB also for web communication

[Stefan Loewe]

Hi all,

I have given a standalone fat client F, a websphere server W (6.1) with servlet container W_Web and EJB2 container W_EJB, and an LDAP server L. F opens a SSL connection to W, authenticates towards W_EJB by username and password and then uses services provided by my SLSB over there. W contacts L for the authentification.

My key question is:

what do I have to do that F, when it has authenticated successfully with W_EJB, can call W_Web such that W does not consult L a second time? (and of course, that F cannot connect to W_Web when the authentication with W_EJB failed)

This is somehow a reversed identity propagation.

I have three ideas to solve this problem.

1) When F logs into W_EJB, it uses a LoginContext. After successful authentication, the LoginContext ha a Subject s which contains username and password. I could take username and password from s to make a Basic authentication with W_Web; however I do not know whether W does contact L a second time.

2) Actually, I have tried (1), but I am not able to find out whether W contacts L a second time or not *). However, I have observed that the communication of F with W_Web contains a LTPA token (as cookie), and that this token seems to contain information that F is authenticated. Therefore, if I could extract the LTPA token somehow from the communication with W_EJB, I could just send it to W_Web. However, I have read that LTPA token is of no use in a non-container environment, and F is not running inside a container. Anyway (I dare say anyway, as F does receive a LTPA token when communicating with W_Web, so it is in a way useful on the fat side, F), I see no way to get hold of the LTPA token in the W_EJB communication - I do not even know whether a LTPA token is contained in the stream.

3) If I cannot see the LTPA token on the W_EJB communication, I could send an user defined token and configure both W_EJB and W_Web login to produce and acccept this token.


What is the correct, recommended approach? One of the three? Something else??


Best greetings,
Stefan

*) This is because my development setup can not use L. It falls back to the file based authentication DB.