On 9 Nov 00, at 9:38, Keith L. Musser wrote:
> Good points - see below..
>
>
> >1. I'm not sure I understand how this works, unless you use some
> >form of transport layer security--because as far as I know, there is
> >no way to indicate the session to which a remote call belongs
> >except by using implicit parameters. Can you explain more how
> >this works?
>
>
> (Remember, I just picked this up from another mailing list, so my
> thoughts are only an interpretation -- and I haven't spent much
> time thinking about it.)
>
> I believe the idea is that if you have a reference to such-and-such
> EJBObject or home interface, then you must have gotten it via
> and authenticated lookup.
Hi Keith,
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).
>
> >2. JNDI lookup is not spec-compliant with EJB security. Consider
> >the case where a client serializes the home interface handle, and a
> >different client (with a different user) deserializes and uses it. This
> >new user has unauthorized access.
>
>
> I don't know how JBoss does handles, but I believe I would do it
> by serializing the JNDI name to the home interface and the primary key
> (in the case of entity beans, at least.)
>
> In the case of session beans, I'd probably do the same, but using
> some unique id for the session bean, which is outside the standard
> EJB spec for the home interface. (I.e. include a public "lookup" method
> in the home proxy which can find the right session bean.)
>
> In the case of home interface, just serialize the JNDI name.
>
> Then the user must be authenticated to deserialize the handle.
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.
>
> >By the way, in my opinion the real overhead is in reauthenticating
> >the client with each remote call--not the cost of transporting the
> >principal and credential. To my knowledge, this can only be fixed
> >with a session-based secure transport (e.g. SSL/TLS) and a
> >"trusted client" token.
>
>
> Of course you are right here, assuming the EJB server must authenticate
> the user.
>
> In my case, the client is a web server and is trusted. So I want my
> EJBs to trust that the client authenticated the user.
>
This is on the "to-do" list. Want to volunteer? :-)
-Dan
>
> For my application, I prefer a high-performance method of telling the
> EJBs who the user is, but letting the client be responsible for
> authentication when a web-session is started.
>
> >
> > Has anyone considered this, which should have better performance can
> > passing the information with each invocation? Are there any drawbacks
> > to this approach?
> >
> > [ This idea came from John Ellis on the jonas-users mailing list,
> > message dated November 8, 2000. ]
> >
> > - Keith
> >
> > -----Original Message-----
> > From: Oleg Nitz <[EMAIL PROTECTED]>
> > To: jBoss <[EMAIL PROTECTED]>
> > Date: Monday, November 06, 2000 6:16 AM
> > Subject: Re: [jBoss-User] problem with ctx.getCallerPrincipal()
> >
> >
> > >Hi jBoss,
> > >
> > >Keith L. Musser wrote:
> > >KLM> For my application, my beans need to know who the end-user is.
> > When I
> > >KLM> call the "getCallerPrincipal()" method in the SessionContext or
> > >KLM> EntityContext, I receive "null".
> > >
> > >KLM> Does jBoss propagate the caller principal per the EJB spec?
> > >Yes.
> > >
> > >KLM> If so, how can my client set it initially?
> > >The simplest way: call
> > >org.jboss.system.SecurityAssociation.setPrincipal()
> > >on client.
> > >
> > >Other way: use JAAS, see
> >
> >http://www.mail-archive.com/[email protected]/msg04170.h
> > tml
> > >
> > >Sorry, the documentation on this topic is not ready yet.
> > >
> > >Best regards,
> > > Oleg
> > >
> > >
> > >
> > >
> > >--
> > >--------------------------------------------------------------
> > >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]
