FYI, I'll be hanging out on #picketlink as "mriet" for the coming days. Feel free to ping me..

The full IRC conversation I had with Anil Saldhana is included below.

But for those of you who'd rather just see the summary:

• Use SSL to authenticate when sending JMS message
• Send user/pass in JMS message (sinds it's already protected/encrypted using SSL, which takes care of any man-in-the-middle issues).
• Instead of having the (jBPM) engine call a service that retrieves the necessary info, have the MDB receiving the JMS message authenticate to the jBPM engine itself.

Wrapping the drools/jbpm engine in an authentication layer is a really good idea: unfortunately, the problem described in this post needs to be fix ASAP, and adding a security layer to the drools/jbpm engine is a full-fledged feature.

In the end, I ended up simply using the JAAS mechanisms to login as the user and thus retrieve the Subject for that user. The Subject of course contains a "Roles" principal with the list of roles that that user belongs to.

<mriet> hi, sorry to bother: help or advice on https://community.jboss.org/message/860844#860844 is very much appreciated.

<asaldhan> mriet: read your description

<mriet> asaldhan, thanks!

<asaldhan> mriet: you are talking about mutual authentication MASSL  at the JMS level.  Then you want to extract the principal out of the x509 certificate representing the caller/client and then pass it as JMS message?

<mriet> asaldhan, I believe so. The challenge is providing a way to dynamically authenticate a user via JMS.

<mriet> dynamic in the sense that it will be runtime..

<asaldhan> mriet: as long as the server side keystore holds the certs for all possible users, it should be fine to do MA-SSL

<mriet> asaldhan, okay, thanks -- especially for pointing me to MA-SSL of which I wasn't aware yet.

<mriet> asaldhan, in general, I'm just looking for a way to securely pass an authenticating token/info via JMS -- Assumed that SSL would be the best choice.

<mriet> asaldhan, passing a password in the JMS message is too susceptible to a man-in-the-middle attack, I think.

<mriet> asaldhan, lastly, have you seen any use of picketlink in JMX mbeans?

<asaldhan> mriet: SSL mitigates mitm attacks

<asaldhan> mriet: not seen PL usage in mbeans yet. You can be the first.

<mriet> asaldhan, LOL.. nice! ( being the first)

<mriet> asaldhan, of course: use SSL to authenticate the JMS user, and then have the mbean user send his password (encrypted using SSL)

<mriet> asaldhan, do see any problems doing that? ^^

<asaldhan> mriet: where is the password coming from?

<asaldhan> from the JMS user who will send it as JMS content over SSL?

<mriet> asaldhan, good point. yes.

<asaldhan> mriet: lets start with what the mbean does?

* asaldhan is trying to understand the usecase so that he can provide a simple solution that works across app servers

<mriet> asaldhan, well.. basically, the mbean would look up the groups that the "real" user (vs. the jms user) belongs to.

* mriet knows that that sounds wrong.. :/

<asaldhan> mriet: forget security aspects

<asaldhan> mriet: assume that we are running without security. Describe the functionality you are trying to achieve and then we will secure it

<mriet> asaldhan, basically, users can only modify and access jbpm human-tasks that they're allowed to. that's built into JBPM. for example, see this class:

<mriet> https://github.com/droolsjbpm/jbpm/blob/6.0.x/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task/identity/JAASUserGroupCallbackImpl.java

<mriet> asaldhan, for example, you could start a jbpm process that would assign a human-task to a particular group.

<asaldhan> mriet: this is running as a web app?

<mriet> asaldhan, the jbpm engine needs to be able to look up which users are part of that group in some cases, so that the users know that they are eligible to take that task

<mriet> asaldhan, yes

<mriet> asaldhan, with REST, it works fine.

<asaldhan> mriet: ok.  we have a webapp within which we need to understand what users can do. Correct?

<mriet> asaldhan, correct. It's about accessibility via JMS (not REST).

<asaldhan> mriet: you need to access it via JMS?

<mriet> asaldhan, yes

<asaldhan> mriet: PicketLink is a Java framework which provides authentication, authorization and permission.   Lets keep that in mind and proceed to solve your use case.

<asaldhan> mriet: Use SSL.  Forget MASSL.

<mriet> asaldhan, got it

<asaldhan> mriet: the JMS user will provide user/pass  via JMS message.  Write a PL JMS handler that will do the authentication.

<asaldhan> mriet: dont use JMS security but use PL JMS handler to undertake the authentication

<mriet> asaldhan, awesome, got it. (PL does the complicated stuff!)

<asaldhan> JMS message handlers work in all app servers

<asaldhan> mriet: PL does not have app server dependency.

<asaldhan> mriet: as long as CDI is there.

<asaldhan> mriet: all app servers have it.

<mriet> asaldhan, .. I can just use it on the client side, and everything is automagically taken care of on the server side (decryption, etc.. )?

<asaldhan> mriet: then you need to transport the security information to your jbpm engine.

<asaldhan> mriet: the JMS handler is serverside

* asaldhan is using his JMS knowledge of 10+ years ago

<mriet> asaldhan, no problem. got it.

<asaldhan> mriet: then in your jbpm engine, you can have another PL authenticator, authorization and permission stuff

<asaldhan> this should all be app server agnostic

* asaldhan wants mriet to copy/paste this conversation on the forum thread.

<mriet> asaldhan, will do (copy/paste)

<mriet> asaldhan, that's a really good idea that I hadn't thought of: put a authenticator *inside* the engine, instead of having the engine go out to figure who's using it..

<mriet> asaldhan, thanks very much for the quick response and all of the help!

<asaldhan> mriet: security does not have to be complicated. :)