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.
>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.
>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.
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]
