Hi Keith,
Yes, you can do that. :-)
-Dan
On 10 Nov 00, at 9:18, Keith L. Musser wrote:
> Dan -
>
> But I would be able to turn off database authentication and just use the
> propagation of the Principal, right?
>
> (And that should be as efficient as the way I'm using it now.)
>
> If so, it meets my purpose. :)
>
> - Keith
>
> -----Original Message-----
> From: Dan OConnor <[EMAIL PROTECTED]>
> To: jBoss <[EMAIL PROTECTED]>
> Date: Thursday, November 09, 2000 8:58 PM
> Subject: Re: [jBoss-User] problem with ctx.getCallerPrincipal()
>
>
> Hi Keith,
>
> Actually, if you use my database security implementation (which
> doesn't yet cache) you should see outrageous performance
> degradation. Complain away. :-)
>
> (A completely in-memory implementation should add very little
> overhead.)
>
> -Dan
>
> On 9 Nov 00, at 18:34, Keith L. Musser wrote:
>
> > Dan,
> >
> > I re-ran my timing comparisons - it seems the method call slows down
> by
> > about 0.2 msec on my machine, which is only 10% of a call to a
> > "do-nothing" method on a stateless session bean.
> >
> > So I can't complain about the overhead. I'm not sure why my initial
> > timing measurements seemed to find a bigger overhead.
> >
> > - Keith
> >
> > -----Original Message-----
> > From: Dan OConnor <[EMAIL PROTECTED]>
> > To: jBoss <[EMAIL PROTECTED]>
> > Date: Thursday, November 09, 2000 11:01 AM
> > Subject: Re: [jBoss-User] problem with ctx.getCallerPrincipal()
> >
> >
> > On 9 Nov 00, at 10:30, Keith L. Musser wrote:
> >
> > > >This on/off authentication (either you can get the reference, or
> you
> > > >can't) would invalidate all EJB-specific security. You could
> neither
> > > >use isCallerInRole nor getCallerPrincipal, nor could the container
> > > >use the declarative access control in the deployment descriptor
> > > >(because it would not know the identity of the caller).
> > >
> > > I'm saying that the Principal and Credentials are passed from the
> JNDI
> > > lookup
> > > into the Home interface. So it knows who's calling; and when the
> home
> > > interface creates an EJBObject, it propagates the Principal /
> > > Credentials.
> >
> > Hi Keith,
> >
> > I think I might see where we're missing each other. Our application
> > server is stateless. In other words, it doesn't remember anything
> > about the clients that are "out there." Even a stateful session bean
> > is accessed by a "stateless" client that uses a private key. So any
> > information you want to be associated with a call (such as principal
> > and credential) needs to be propagated on the remote call.
> >
> > So in that sense, it doesn't matter whether you get the user
> > information through JNDI or through a static or thread-local variable
> > (our two methods). You still have all the same costs; it's just a
> > matter of which API to use.
> >
> > >
> > > So yes, the EJB security model still holds, but you can do the
> > > authentication
> > > only once and remember it.
> > >
> > >
> > > From the client's perspective, they pass the Principal / Credentials
> > to
> > > the
> > > JNDI system during the lookup. After that, they just keep track of
> > the
> > > references they receive.
> > >
> > > >Do you mean embed the user principal and credential in the
> > > >serialized handle, and have the JNDI authentication happen
> > > >automatically on deserialization? This could expose the principal
> > > >and credential to discovery, and would limit the usefulness of the
> > > >serialized handles.
> > >
> > > No - that's not what I had in mind. I was imagining something like
> > > the thread-local Subject in JAAS. So when the deserialization
> occurs,
> > > the principal / credentials should be accessible via JAAS, but
> > > certainly not stored in the handle.
> >
> > We use a thread-local or static variable (your choice).
> >
> > -Dan
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Problems?: [EMAIL PROTECTED]
> > >
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
