Hi Leonardo,
Thank you for your input. Identity propagation for JMS, as well as for
other protocols like REST would be useful to standardize. At this point,
the JSR 375 1.0 feature scope is focused on some more fundamental
problems, but we will certainly consider your suggestion going forward.
Would you please add your suggestion to the JIRA
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC ?
Thanks,
Alex
On 5/2/15 12:37 PM, Leonardo Loch Zanivan wrote:
> In JavaEE 7 we have some security problems with WebSocket and JMS
> listeners (MDB).
>
> In WebSocket the problem it's a bit weird.
> An authenticated session, with a valid Session.getUserPrincipal()
> doesn't authenticates in the container on websocket events, so EJB /
> CDI calls are unauthenticated.
> I've tested with WildFly 8.2.0 and GlassFish 4.1, with a sample app
> which calls EJB methods from @onOpen, @onClose and @onMessage.
>
> In the JMS case, we 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
> WebSocket sample app source using library:
> https://github.com/panga/websocket-auth
>
> What do you guys think?
>
> Best Regards,
> Leonardo Zanivan