Nigel,
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.
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>
wrote:
> Leonardo,
>
> On 16/05/2015 21:46, 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
>