#mcollective

grilled-cheese: yah I played with jaasAuthenticationPlugin when writing the LM book. It works well but is non-trivial setup

however authentication at the middleware layer is almost irrelevant if you're doing end->end encryption like you should be

agreed

so the key management per user is the tricky and much more important stuff

I like tieing as many thing to the one common identity system as possible so with a single action accounts are updated, created, or deleted

if you accept the standard deployment document of using the openssl method, then just handwave over the middleware it’s an extra step to change the admin broker password

you can’t get around having to revoke their certificate on every server, but hopefully you’re using puppet to make that easier

when asking the question, what’s the worst that can happen, with broker admin you could disrupt the communication bus

I’m still new to mco, but it was my understanding that while end-to-end encrypted aes payloads are supported, they were generally frowned upon

the broker auth is almost not important at all for the 'what can someone do'

authorization lives in mco not the broker

you need to manage authorization plugins and their keys too

someone with broker credentials can gain a lot of insight into who is doing what etc on a mco+ssl network and probably do nasty DOS things etc, but they cant run commands on nodes, certainly managing access to the broker is important etc

just saying the authorization plugins are super important dont forget abt them

agreed

Since I hit a wall for a moment with JAAS, I switched to getting Jetty switched to AD

which turns out isn’t much easier

I could just turn that off, but it would be handy to have for debugging purposes when things go haywire

the biggest payoff for me personally was getting Jolokia REST API enabled. Hawtio == easy debugging

jorhett: so you replaced the mco stomp connector with jolokia clients?

ah, hawtio integration, nevermind

hadn’t heard of that one before