Hi Rickard,
Once again, you are exactly correct. :-) The typical stand-alone
client will have a single identity, regardless of the number of
threads. That's why "server" and "local" are separated.
If you want, though, you can make your client associate identity
with threads. Just call setServer(). (Because this is controlled by a
static boolean variable, this is already automatically done for any
client running in the jBoss VM, e.g. Tomcat.)
Guys, all the basics ALREADY work except TLS:
* web integration
* bean-to-bean calls (even across our eventual cluster)
* access control,
* isCallerInRole()
* getCallerPrincipal().
The trick, now, is to make it work right. This means caching,
adding the concept of a group to role mapping, making the
database mappings flexible, concept of a trusted client, making
Tomcat use our security and vice versa (so you don't have to
configure two systems), adding a J2EE client container with a sign-
on, option to refuse to deploy a bean without security, etc.
-Dan
On 24 Oct 00, at 19:29, Rickard �berg wrote:
> Hi!
>
> marc fleury wrote:
> > |2. the SecurityAssociation
> > |... on the client side works global (static) to follow the idea of jaas
> > |it should work thread based, so the principal/credential should be
> > |ThreadLocal on the client side too.
> >
> > yes, I am not sure I understand why it is separated "server" vs "local"
>
> Probably because on client you want to set in on the VM level so that
> any thread calling a server will have the right security association.
> Otherwise you would have to re-authenticate for each thread.
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
>
