Jon Tirsen wrote:
>
> > > Yes, but there is no standard way for the
> > application-client-container to
> > > propagate the sec. attr. to the ejb-container. More on that later.
> >
> > IIOP, Kerberos, IPSEC, HTTP, security context over RMI, etc.
>
> Yes, there are standards, but no Java-standard. It's the last one "security
> context over RMI" that is not standardized.
> Or...is it? I haven't read about such a thing. I thought that each vendor
> implemented their own proprietary (implicit, that is) propagation technique.
EJB servers use RMI + something. The transaction or security context are
that + something. Unlike IIOP it is not specified in any standard, so
although they all use RMI, it's not portable.
But generally you get the RMI stubs from a particular server, so you get
an implementation that does security + tx propagation, so you don't
care. An EJB server from vendor A talking to an EJB server from vendor B
will work, since A will act as any other client of B.
If both use JAAS (Subject.getSubject()) they can share the same security
context.
arkin
>
> > > No, it doesn't. But shouldn't it?
> > > JAAS deals with propagating sec. attrs. within an application. I believe
> > > that for JAAS to be semantically complete (even within J2SE,
> > which includes
> > > RMI), it needs to be able to propagate sec. attrs. through RMI.
> > Else, the
> > > semantics of an RMI-method call is inconsistent. When calling
> > an RMI-method
> > > residing on the same VM the context is propagated, else it is not.
> >
> > For same-VM you can simply carry the AccessControlContext around (same
> > Subject).
> >
> > For remote methods, you can serialize the Subject send it along and have
> > it reauthenticated on the server side.
>
> Yes, you can use an explicit propagation technique. That is not actually a
> very good idea. If EJB followed that approach every method-call would have
> an extra parameter for transaction-context. And you would have to rely on
> each developer to always propagate correctly. Not a very good idea....
> Implicit propagation, I believe (see above) is not standardized for RMI.
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".