Seems like I'm getting closer to the problem. I've debugged a little...
The first major problem I encountered is that
org.jboss.ejb.plugins.SecurityInterceptor uses SecurityAssociation to get
current Principal and its credentials. The problem is, that if you search
for "SecurityAssociation.setPrincipal" the whole source code contains only
three of them: two in ClientLoginModule and one in SecurityInterceptor,
where its sets definitely NOT A NULL there. So, where is
SecurityInterceptor.setPrincipal(null)? SecurityInterceptor only attempts to
re-login if SecurityInterceptor IS null, judging by the code... The only way
for this code to work is when each user/(user's bean) has its own thread on
the server. Or am I missing something?
Alexander Klyubin
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Oleg Nitz
Sent: Monday, January 22, 2001 19:41
To: jBoss Developer
Subject: Re[4]: [jBoss-Dev] jaas - commit()
Alexander Klyubin wrote:
> This shouldn't help if I wish to work under different identities in the
same
> thread SEQUENTIALLY though (e.g. test clients running security tests in
the
> same thread, servlets, ...).
Then create different LoginContexts SEQUENTIALLY or just call
SecurityAssociation.setPrincipal and SecurityAssociation.setCredential
with different user names and passwords.
> Anyway, I checked some jBoss code, if I remember correctly, setServer()
> makes ClientLoginModule use TLS for storing principal.
If "TLS" means ThreadLocal, then you are right.
Oleg
