St2: StackStorm should support LDAP groups for RBAC

[manasdk]

StackStorm RBAC roles should mirror LDAP roles when using ldap. At least it should be possible to do so with some configuration and mapping.

In general too it would be nice if StackStorm could "slurp" up roles from an external provider for RBAC purposes.

[manasdk]

Copying over message from slack since linking to the archive is not always possible -

ckamps [10:18 AM]
@kami: thanks for the follow-ups. On the lack of automatic LDAP group to role mapping: This is a pretty key requirement for our enterprise use case given the fact that we have an enterprise access management service that already manages membership of LDAP groups that make up enterprise level role definitions. Writing, operating and maintaining custom code to synchronize information that is already available via a common interface (LDAP) is not something we're interested in doing. Enabling LDAP group to role mapping with relatively frequent and automated synchronization is our interest. We don't expect to care about specific users in the configuration of a tool such as StackStorm. It's the roles associated with LDAP groups in which we'd expect to represent user oriented policy.

_upd enykeev: formatting_

[jjm]

The way that elasticsearch handles this may be a good reference.

Basically you create a role_mapping.yaml that maps ldap groups to a local group.

[Kami]

@jjm Thanks for the suggestion.

I will look into, it indeed sounds like something similar to what we were thinking about doing :)

[codyaray]

It seems like the current LDAP auth/RBAC workflow is something like

1. having a user login via LDAP (which creates the user in st2)
2. the user now has an account and permission to do nothing
3. request that an admin create and sync an assignments file
4. now the user can refresh/re-login so they have the proper permissions.

Ideally, when a user logs in with LDAP (or other external auth with some concept of groups/roles), they would automatically be assigned to roles based on the groups of which they are a member.

An example from my own Active Directory mapping:

  "memberOf": [
    "CN=Hipchat Users,OU=Hipchat,OU=Groups,DC=domain,DC=com",
    "CN=Systems Support,OU=Shared Services,OU=Distribution Groups,OU=Groups,DC=domain,DC=com",
    "CN=SS - Monitoring Users,OU=User Groups,OU=Groups,DC=domain,DC=com",
    "CN=JIRA - Administrators,OU=JIRA,OU=Groups,DC=domain,DC=com",
    "CN=Confluence - Admins,OU=Confluence,OU=Groups,DC=domain,DC=com",
    "CN=DevOps,OU=Distribution Groups,OU=Groups,DC=domain,DC=com",
    "CN=UNIX-Support,OU=Shared Services,OU=Unix Groups,OU=Groups,DC=domain,DC=com",
    "CN=Unix-Admins,OU=Shared Services,OU=Unix Groups,OU=Groups,DC=domain,DC=com",
    <and many more, 120 groups total>
  ],

So, yeah, we have a lot of groups. I'm sure that some of these groups could map to StackStorm roles.

A few things that become clear after looking at this, the user requirements may be

1. scope searches to a groups_ou. This would be OU=Groups,DC=domain,DC=com for the above example.
2. specify a mapping of specific group DNs to StackStorm roles
3. ignore any external groups that aren't mapped to StackStorm roles
4. a user's permissions continue to be the union of permissions for all roles (mapped to external groups)
5. this mapping would be setup by a StackStorm admin in advance

From a usability perspective, the goal here is that a user that's new to StackStorm would be able to login/auth for the first time and immediately be productive with the correct permissions.

[Kami]

@codyaray Thanks for chiming in.

What you wrote is basically what we had in mind after discussing it with some of our existing users and what we plan to implement in the near future :)

[jjm]

The creating an local user in ST2 is not ideal, if we remove an user from AD his account should not need to be cleaned up from another platform.

Really the user should login and get her / his permissions from LDAP and it not create local copies of the accounts.And allow them to start working straight away.

[Kami]

@jjm With LDAP authentication backend you don't need to create any local user in StackStorm (besides system / stanley user that is, but that's not related to auth or RBAC).

Only thing which you need to create / define manually is role definitions and user role assignments. And once this issue is implemented, you will also need to define another file which maps StackStorm roles to AD / LDAP roles.

If you use LDAP backend and you delete user from LDAP, that user also won't have access to StackStorm anymore once the currently active auth token expires. It's true that user role assignment file will be left as it, but that's a feature and can be cleaned / rectified later.

[codyaray]

Made any progress on this?

[Kami]

We've been busy with other things so we haven't made any progress on this yet (we also don't have an ETA yet atm).

[codyaray]

We're still watching this issue. :)

[akabraab]

This is a key requirement for us as well and eagerly waiting for an update on this. The issue has not been updated in a while and it would be nice if you could chime in whether this is still being considered and if there is real possibility of this being addressed.

[ckamps]

Shouldn't title use the term "LDAP groups" vs "LDAP roles" given that groups and not roles are represented via LDAP?

For example:

"StackStorm should support LDAP groups for RBAC"

[ckamps]

If a community member was interested in driving the implementation, would it be feasible due to what is held back as closed source in support of the overall RBAC capability?

[ckamps]

When this feature is implemented, I would like for the current required field group_dns to be eliminated or at least made optional so that all of the authorization rests solely on the use of the LDAP group to role mapping.

If requirement for this setting persists, organizations will continue to have to onboard individual users to some centrally maintained "st2 users" group in addition to role-oriented LDAP groups vs simply deferring to the role-oriented LDAP groups defined elsewhere in the st2 config.

Managing a common "st2 users" LDAP group in addition to the role-oriented LDAP group is unnecessary overhead for an organization to maintain.

https://docs.stackstorm.com/authentication.html#ldap-enterprise-edition

[Kami]

@ckamps Most of the changes for that would actually need to be done in StackStorm core (st2 repo) and not auth backend so in theory it should be possible to do it without having direct access to enterprise bits source code.

As far as group_dns change goes - this would need to be made in the backend. Imo, making it optional is reasonable once we have role sync in StackStorm.

[Kami]

Just a quick update and heads up - I finally started to work on this feature.

When this feature is implemented, operator will be able to write YAML files which contain definition on how to map remote LDAP groups to StackStorm role(s) (those files will most likely live somewhere in /opt/stackstorm/rbac, perhaps /opt/stackstorm/rbac/role_maps or similar).

Here is an example of such definition file - https://gist.github.com/Kami/8f91c75a907f9a7c83048bf3b6bd527d

Keep in mind this is just an example definition proposal - actual terminology, file format and location might / will change (feedback welcome).

As described in the example definition file, those mappings will automatically be synchronized in StackStorm every time user logs-in (authenticates) with StackStorm st2auth API.

If for some reason, admin / operator wants to sync roles earlier or more frequently, we will also provide CLI tool for that (st2-rbac-sync-remote-role-assignments [--user=username] or similar). Keep in mind that this CLI tool will probably be separate from st2-apply-rbac-definitions. Apply definitions tools works locally and is fast and the one for syncing remote group to roles will involve network calls to LDAP server, etc. and be slower and as such, I don't want to conflate those tools together.

If operator wants a more frequent sync, they can also decrease the default value of TTL for the auth token. This means user will need to authenticate more often and as such, roles will be synced more often - that's also really the main purpose behind the auth token (and how most other similar systems are implemented as well) - synchronizing roles on every single API call or similar would simply be too slow and expensive.

The issue name and examples referenced above, etc. mention LDAP, but the whole thing is actually being implemented in a generic fashion by extending functionality provided by auth backends - https://github.com/StackStorm/st2/pull/3280.

This means that the feature won't be tied and coupled to LDAP and users will be able to extend existing auth backends or write new auth backends which allow retrieval of users groups from other places (e.g. from a flat file, from a 3rd party service or product such as various existing user management based HTTP SaaS services, etc.).

If everything goes according to plans, first working prototype (with docs, etc.) should be available some time late next week and testers will be welcome then :)

Comments and feedback on terminology, etc. are welcome.

/cc @codyaray @jjm @ckamps @akabraab @lakshmi-kannan @dzimine

[codyaray]

Awesome, glad to see it!

On Wed, Mar 8, 2017 at 7:39 AM, Tomaz Muraus [e-mail]
wrote:

Just a quick update and heads up - I finally started to work on this
feature.

When this feature is implemented, operator will be able to write YAML
files which contain definition on how to map remote LDAP groups to
StackStorm role(s) (those files will most likely live somewhere in
/opt/stackstorm/rbac, perhaps /opt/stackstorm/rbac/role_maps or similar).

Here is an example of such definition file - https://gist.github.com/Kami/
8f91c75a907f9a7c83048bf3b6bd527d

Keep in mind this is just an example definition proposal - actual
terminology, file format and location might / will change (feedback
welcome).

As described in the example definition file, those mappings will
automatically be synchronized in StackStorm every time user logs-in
(authenticates) with StackStorm st2auth API.

If for some reason, admin / operator wants to sync roles earlier or more
frequently, we will also provide CLI tool for that (
st2-rbac-sync-remote-role-assignments [--user=username] or similar). Keep
in mind that this CLI tool will probably be separate from
st2-apply-rbac-definitions. Apply definitions tools works locally and is
fast and the one for syncing remote group to roles will involve network
calls to LDAP server, etc. and be slower and as such, I don't want to
conflate those tools together.

If operator wants a more frequent sync, they can also decrease the default
value of TTL for the auth token. This means user will need to authenticate
more often and as such, roles will be synced more often - that's also
really the main purpose behind the auth token (and how most other similar
systems are implemented as well) - synchronizing roles on every single API
call or similar would simply be too slow and expensive.

The issue name and examples referenced above, etc. mention LDAP, but the
whole thing is actually being implemented in a generic fashion by extending
functionality provided by auth backends - #3280
https://github.com/StackStorm/st2/pull/3280.

This means that the feature won't be tied and coupled to LDAP and users
will be able to extend existing auth backends or write new auth backends
which allow retrieval of users groups from other places (e.g. from a flat
file, from a 3rd party service or product such as various existing user
management based HTTP SaaS services, etc.).

Comments and feedback on terminology, etc. are welcome.

/cc @codyaray https://github.com/codyaray @jjm https://github.com/jjm
@ckamps https://github.com/ckamps @akabraab
https://github.com/akabraab @lakshmi-kannan
https://github.com/lakshmi-kannan @dzimine https://github.com/dzimine

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackStorm/st2/issues/2509#issuecomment-285042523,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACsHoBDwEYQmF0DfLor4HkmftigcNp3ks5rjq-GgaJpZM4HcZI-
.

[Kami]

Just a quick heads up everyone - feature is now (mostly) implemented and working end to end - https://github.com/StackStorm/st2/issues/2509 (docs at https://github.com/StackStorm/st2docs/pull/434).

If you feel a bit adventurous you can check out those changes and test it out.

If you don't want to deal with manually checking out the changes and / or building the packages you can wait a couple of more days for the PR to be reviewed and merged. Once it's merged, new v2.3dev packages will be built and then you can more easily test those (with installer script you just need to use --staging --unstable flag).

Feedback is welcome.

At the very least you can check out the docs and point out if something is not clear or doesn't make sense :)