On Thu, Jun 4, 2015 at 10:43 AM Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:
> Leonardo,
>
> Sorry for the delay in responding. I've been unsure how best to approach
> this, given that the JMS specification has
> little to say about security currently.
>
> My understanding is that you want the security principal of the sender of
> a JMS message to be automatically propagated
> to the thread invoked by an async message consumer, at least in the case
> where the sender and consumer are both running
> in a Java EE application.
>
> I'd welcome other views on how common a use case this is.
>
> It poses some obvious difficulties, most notably how we prevent this
> providing a security vulnerability, since it would
> mean that any arbitrary consumer of a message would obtain elevated
> privilege. There would need to be way to ensure that
> only authorised clients were able to create such consumers. Since JMS does
> not currently define any way of restricting
> access to particular queues and topics (though individual vendors do), we
> would probably have to extend the spec in that
> area as well.
>
> Rather than provide this as a single specific feature, I suggest
> assembling a list of what features would be needed to
> allow you to build a portable application which has the behaviour you
> require. Since you've already build such an
> application you presumably already know where you've had to resort to
> non-portable code.
>
> * What is it that we want to propagate:
> - a javax.security.Principal?
> - Java EE security role?
> - something else?
>
>
*I agree with you, we have more than one topic to cover.1. In the basic use
case we need to know message sender identity. Currently we append in the
message body (getCallerPrincipal)2. Another use case is programatic
authorization of message through security roles (isCallerInRole)3. The
final use case is RunAs caller identity. In this case we would have some
security concerns, but it should be an explicit method, so each vendor or
application could take care of this.*
> * Is this currently serializable, so could be sent from one JVM to another
> (i.e. attached to a JMS message as a message
> property)
>
*Yes, Principal, Subject and Groups are Serializable because of JVM
intercommunication, cluster, EJB remote, etc.*
>
> * will this always have the same meaning on the receiving system? (Bear in
> mind that a JMS system may have a mix of Java
> EE and non-Java EE clients)
>
*Yes, Principal, Subject and Groups are from java.security package which is
Java SE Platform, we could integrate with non Java EE clients.*
>
> * Once extracted by the receiving system, what API does the MDB need to
> call to change to the new principal or role? Is
> there already API to do this, or is a new "runAs"-type method required?
>
*I don't know a standard API to RunAs, I think that only vendor specific
APIs can do that. However, we could login again using JAAS (LoginContext),
in this case we also would need user credentials.*
>
> Once we know what features would be needed we can see what spec(s) would
> need to be changed to provide them.
>
> Nigel
>
>
>
> On 21/05/2015 16:05, Leonardo Loch Zanivan wrote:
> > 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
> <mailto: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>
> > <mailto: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> <mailto: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
> > >
> >
>