Sure, that's what I tried to do. But, on the client everything's fine.
ClientLoginModule works OK. SecurityAssociation holds the correct Principal
and credentials. But, only the first identity is sent for logging into
jBoss. Subsequent ones (even when Principal changes) are not
authenticated -- so, on the server, everything works under the first
identity authenticated (works like this only if first identity has enough
permissions for all the calls attempted under all identities -- e.g.
Administrator).
I trace DatabaseServerLoginModule and it's login() is called only the first
time.
My question is, if everything is fine on the client, may be there's a
problem on the server? If it were that easy, I wouldn't ask, but the curious
point is, that in case the first identity does not have enough permissions,
DatabaseServerLoginModule::login() is called to authenticate subsequent
ones.
If I were to describe jBoss authentication as a black box, I would say
something like this. As soon as server detects that bean to be invoked
should be secured, it checks whether caller's server-side Subject has enough
privileges. If not (not logged in yet, or just not enough permissions) it
requests authentication from client side (well, I don't think it goes from
server to client, but the idea is the same). In this case, client-side
Subject is sent to server to update current LoginContext.
Is there any code on the client-side, that tries to call a secure bean, and
if an security exception is caught tries to pass current client-side Subject
to the server and tries once more?
I can look at the code, but I don't know where to start to see how
client-side invocation and, particularly, propagation of Subject works.
Regards,
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
