Yes, I'm suggesting that onMessage *could* run as sender identity.
I don't think that identity is coupling, it's infrastructure.
EJB async isn't a queue, so there isn't persistence, priority or
scalability.
But I'm trying to cover two important use cases.
1. Answer the question "Who is the sender"? (Currently it always return an
anonymous principal)
2. Optionally run onMessage as sender identity. (To eliminate boilerplate
and vendor specific code)
On Thu, May 21, 2015 at 11:43 AM Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:
> Leonardo,
>
> On 19/05/2015 01:18, Leonardo Loch Zanivan wrote:
> >
> > The problem is that JMS doesn't address security context propagation
> (JAAS principal and subject), so an authenticated
> > user principal sends a message to a queue and the receiver is
> unauthenticated or "annonymous" and there isn't a simple
> > way to workaround that.
> >
> > In modern cloud multi-tenant SaaS applications we have tons of JMS
> topic/queues, so we need to append login, part of
> > infrastructure, into the message and authenticate again. We need some
> user info, as tenant, roles, etc.
> >
> > I mean that JMS could behave similar to EJB, propagating security
> context even on remote invocations, could be optional
> > for backward compatibility.
>
> What do you mean by "security context propagation" in a JMS context? Are
> you suggesting that the MDB's onMessage method
> somehow runs with the same principal/subject as the application that sent
> the original message?
>
> It sounds as if the MDB is being used as if it were an async EJB call,
> with the sender and receiver much more closely
> coupled than is the case with JMS.
>
> Nigel
>
>
> >
> > My example shows how to workaround that in JBoss containers using
> interceptors.
> >
> > On Mon, May 18, 2015 at 7:02 AM Nigel Deakin <nigel.deakin_at_oracle.com
> <mailto:nigel.deakin_at_oracle.com>> wrote:
> >
> > Leonardo,
> >
> > On 16/05/2015 21:46, pangalz_at_gmail.com <mailto:pangalz_at_gmail.com>
> wrote:
> > > In JavaEE 7 we have some security problems with MDB JMS listeners.
> > >
> > > JMS don't have a simple way to propagate the security
> > > context, so in the MDB listener the user principal is "anonymous".
> > >
> > > Currently we can append security credentials with the message and
> login
> > > again, but it's big a security hole.
> > >
> > > Although we can workaround these issues with interceptors and
> vendor
> > > specific security managers, it's a common use case for JavaEE
> > > applications and an important requirement for cloud/SaaS
> applications.
> > >
> > > I've created an open-source library to get workaround these
> problems in
> > > JBoss/WildFly.
> > > It's called "JBoss Security Extended" and is available on maven
> central
> > > with GAV "com.github.panga:jboss-security-extended:1.0.0".
> > >
> > > Library source and docs:
> > > https://github.com/panga/jboss-security-extended
> > >
> > > What do you guys think?
> > >
> > > Best Regards,
> > > Leonardo Zanivan
> >
> > I looked at the page you mentioned above, and I'm not clear to me
> what you are suggesting. Would you like to follow up
> > your message with a summary of what you are proposing? I'd be happy
> to discuss it.
> >
> > Nigel
> >
>