Hi!

First of all, thank you for the thoughtful description—I appreciate you taking the time to write the user story in detail, and also review our codebase!

Our relationship with ChatOps auth is, admittedly, complicated. Since it's an often-requested feature, I'll try to answer your questions in as much detail as possible, expand on them, and provide some additional context for future reference. Hopefully, other people will benefit from having detailed and definitive answers to these questions, too.

Brace yourself! Here comes an unexpectedly massive wall of text.

ChatOps access control in StackStorm

1. Native RBAC

I want to grant read only or a layer of both authentication and authorization to other stakeholder but at the same time restrict all calls to the bot and/or list which commands unprivileged users could access.

The short answer: StackStorm does not have a native or "official" way of implementing access control in ChatOps yet, but to some extent it is possible, given you are willing to experiment a bit.

I am going to give the long answer, too—quite a lengthy and curious story, in fact—but first I am going to answer the rest of the questions so that you could just skip the story if you feel like it.

2. 2FA with Hubot

In reviewing the code I noticed the condition for a 2FA command: https://github.com/StackStorm/hubot-stackstorm/blob/master/scripts/stackstorm.js#L94 . What is current/planned use (if any) of this to date? is/will it manage 2FA from StackStorm, hubot, or any 3rd party SAML/LDAP/OAuth service?

Disclaimer: this feature is undocumented and unsupported: it relies on experimental properties, and will change when we implement better access control.

Yes, it's possible to use 2FA with ChatOps aliases. To be precise, it's launch confirmation rather than 2FA, because there's no "first" auth method, but it's a common term for any "external" auth nowadays. Someone called it 2FA, and we just kinda rolled with it. ¯_(ツ)_/¯

@jjm and I built this as a demo a while ago, and while it never been released officially, it's fully functional. I'll be very descriptive and technical here: you're pretty much entering uncharted waters, so it wouldn't hurt to have as much information as possible.

You will need three things for 2FA to work:

• a configured Duo Security pack;
• the "extra:security:twofactor" parameter in your alias;
• export HUBOT_2FA=duo.auth_chatops in your Hubot env variables (/opt/stackstorm/chatops/st2chatops.env).

Restart everything, and you should have it working. Here's what's going to happen when you issue a command:

• if 2FA is enabled in the environment and your alias requires it, Hubot will detect it and freeze the command;
• it will execute duo.auth_chatops with information about your request and a one-time token;
• duo.auth_chatops will send a request through Duo according to your config:
  
• if the action is approved, duo.auth_chatops will execute the announce_success action, which sends an announcement with your token to the StackStorm stream service;
• Hubot receives the event from the stream and "unfreezes" your command if your token is valid.

That's it!

If you followed the links, you must've noticed that the 2FA implementation is not specific to Duo: you can build your own workflow, as long as it accepts the same set of parameters from Hubot and sends either a stream announcement or a failure message as a final step. What's inside the workflow is irrelevant to Hubot: you can launch Duo actions or you can use the astral pack to deny all requests from sunset to sunrise.

Again, this syntax will change in the future, because aliases shouldn't contain user-specific data: they are supposed to be shared and reused across all users and teams. On the other hand, when we decide it's time to change it, it will most likely mean we have a better feature in place, so if you end up using 2FA, don't worry: we won't leave you hanging.

So, about your use case.

At the same time I want to grant read only or a layer of both authentication and authorization to other stakeholder but at the same time restrict all calls to the bot and/or list which commands unprivileged users could access.

You'll have to enable 2FA for the aliases that aren't supposed to be public, and build a workflow in such a way that only you and the stakeholder can confirm the request it sends. Could be Duo or something else. The workflow might require a bit of tinkering, but shouldn't be too hard.

Admittedly, using 2FA as a substitute for access control is a very peculiar way of solving this problem, but if you come up with a workflow that's simple and convenient enough for you to use, I can't see why not.

3. Other ways to implement access control

I've come around a number of hubot scripts - are any of these potentially useful or being considered for integration?

hubot-rbac might work: it's middleware-based, so it's going to verify your access even before the command propagates to our own hubot-stackstorm plugin. If it works, and turns out to be convenient enough to use with StackStorm ChatOps, please let me know, I'll update our knowledge base. I'll also buy @michaelansel a beer the next time I see him. :)

hubot-auth exposes methods for auth, and expects other scripts to use those methods, as far as I can tell. Not a good choice unless you want to modify hubot-stackstorm—and I would really advise against that.

I might not be able to help further, since we don't support third-party scripts, but if you're determined to see this through and figure out a decent way to implement ChatOps access control with StackStorm—and maybe write a guest post about it in our blog—let me know, I'm really interested.

Consider dropping by our community chat in Slack! It's fun, and there's a few people who can tell more about ChatOps auth, too. @jjm and @tonybaloney are auth experts by now, and @pixelrebel has his own implementation of limiting aliases to channels.

The story

Now, the story about why we don't have ChatOps access control yet.

I mentioned earlier that StackStorm having no access control in ChatOps is not just an oversight: as you can probably guess, this feature is requested quite often, and we are well aware of its importance. Most hierarchical companies or large teams have a need to limit access to the bot. For some, it's a necessity—especially when StackStorm runs mission-critical workflows—or even a requirement mandated by a security policy.

If so, why don't we have it implemented yet?

The reason is twofold.

1. It must be done right

Access control in ChatOps is a major architectural change: we need to map chat users to StackStorm users, assign permissions per alias (possibly even per format string), implement permissions for service users, and tie this functionality into core StackStorm RBAC. That's not to mention a multitude of smaller additions and changes.

As if it's not enough, consider the fact that we are building a security layer. Naturally, every security feature is extensively scrutinized: StackStorm often controls mission-critical infrastructure, and we have to make sure it is reliable and safe. No feature at the security layer gets developed, let alone released, until we are absolutely sure we have the time and resources for it.

That said, we are (spoiler alert!) making progress on the issue. But there's another peculiar problem.

2. StackStorm RBAC is not open source

Elephant in the room time! Role-based access control in the StackStorm core is an enterprise-only feature, and ChatOps access verification is supposed to tie into the StackStorm core.

Oh no! What are we going to do now?

Are we going to introduce a crippled version of access control that only allows three and a half users?

Are we going to give everything away and work for $1 a year? (I kinda hope not.)

Are we going to offer a 30-day trial, wiping the entire access list and sending a channel-wide notification about it the moment it's expired?

Are we going to ask everyone trying to run a bot to buy a commercial license for a gazillion dollars? (Yes, please. My paypal is enterprisesales+gazilliondollars@stackstorm.com.)

Shhhh... I'm not telling you. It's a mystery! But whatever we do, Customer Satisfaction Guaranteed.

Future plans

No promises here, but there's a pretty good chance this is going to be implemented in StackStorm 2.2.

We have a great PR by @tonybaloney that lays the groundwork for ChatOps auth, and after we release 2.1 (in a few weeks!), ChatOps access control is one of the candidates to become the next release focus. About time, isn't it?

Well, I hope I was able to answer your question. If you end up doing something interesting with access control in ChatOps, you should definitely let me know! And sorry that was such a long response completely out of the blue. 😛

Good luck!

— Ed

@emedvedev answer here is very helpful, so I renamed Issue title for better search.
Maybe it worth to move it to separated readme page or even blog.

But for now leaving it opened as a great piece of information.

hubot-rbac isn't going to work because they rely on the listener id in hubot to perform the authorization. In stackstorm, all commands are funneled into one listener with a broad regex which then further matches it to a stackstorm command from there. I assume this was done to support reloading the commands on the fly.

I created a fork, which is heavily refactored here: https://github.com/silverbp/hubot-stackstorm. I pulled the 2FA stuff out for now as well as the ability to reload commands. The refactor though does register each command as a separate ID allowing hubot middleware plugins to work better with it such as hubot-rbac. I intend on adding the 2FA and reloading of commands back in as well as fixing up the tests as I get time.

Awesome job! Please let us know how we can help, and keep us posted :) As soon as you add the missing functionality back, we can help with tests and such.

I'm going to create a pull request so we can track it from there, I have some questions. I've also switched to using hubot-auth and hubot-middleware-auth-ext since the hubot-rbac is deny only. I have it working where you can set the roles and possibly rooms in the action-alias and hubot-stackstorm picks it up.

@armab said in slack (talking to @namachieli):

Yeah, at the moment you can't do RBAC with ChatOps.
We discussed that internally. If something like that could be implemented in future, it will be part of the StackStorm Enterprise version.
But we're looking for feedback for this feature. If you could write in short your use case and +1 in mentioned #128, - that'll be very helpful.

My usecase:
I'm part of a Network Operations Center. StackStorm is used to run ops tasks (via ansible) on servers that are distributed at our client locations. Each location has a server and a lot of IoT devices.
I need to give the customer support team access to run a select set of well-defined tasks that are useful in diagnosing (in real-time) what a customer is saying about one or more of their IoT devices. However, the customer support team should not be able to run anything but those well-vetted, and well-defined tasks. They should not, for example, be able to install or upgrade any packs on ST2.
I and my team, on the other hand, would like to use the full power of chatops to perform maintenance operations or query the state of various pieces of our infrastructure. Running ad-hoc commands via ansible, core.local, or core.remote are perfectly acceptable and expected (in addition to more involved ops workflows and actions).
Other groups of people could also use some actions to retrieve various statistics, turn on/off debug logging in certain locations, or trigger the creation of reports. Some form of access control would make chatops (and therefore st2) much more useful to more people.
Currently, I have limited chatops to only the commands that the customer support team needs, and I told them they need to be in a particular channel to do that. Though, technically, there is no channel restriction, it's easier for me to pop into that channel to see what they're seeing when someone reports an issue with a workflow that is available to them.

This would be an excellent capability in my environment. Being able to have other teams invite my bot and query the network, while safely only be able to execute workflows and actions that I deem acceptable would greatly expand the ways in which I could utilize stackstorm.