Chronograf: Map OAuth organization to Chronograf Organization

[jaredscheib]

E.g. InfluxData users from GitHub are automatically added to any number of specified Chronograf Organizations. Basically whitelisting OAuth Organizations (e.g. Github:Influx:* to X and Y =Chronograf Organizations) to Chronograf Organizations.

Needs to be solved in the UI and server for same PR, and for both should prob be completed alongside in the same PR as #1832.

[jaredscheib]

This also seems like a nice-to-have. Is it a req for 1.4.0 or 1.4.x, @nhaugo?

[nhaugo]

nice to have

[jaredscheib]

Current proposal is scheme:provider:optional_provider_org|* --> Chronograf org:optional_role. Thoughts, @nhaugo?

[desa]

@jaredscheib had a bit of a question about this, when do we "apply" the mapping? (A) Is it immediately after the authentication process, we check which oauth organizations, you're a part of and then apply the mapping. (B) Or do we run the mapping each time a user hits /me?

What if when we apply the mapping, the user is already a part of the organization when we apply the mapping? Do we skip the update and let them retain their role in the organization, or do we apply the mapping role?

What about if there's a new mapping that gets created between the time when a user is authenticated. Do they get added automatically to that org, or do they have to have to re-authenticate to be added to the new org?

Additionally, should we store a users oauth orgs in the database? If so, what happens when we detect that you were removed from an oauth org, should we remove you from any of the appropriate organizations?

Most of these are boundary conditions, but would be helpful to have a general idea of what should happen.

[nhaugo]

This mapping should only apply on first login, after that if they are manually changed the manual settings should persist

[nhaugo]

| Additionally, should we store a users oauth orgs in the database? If so, what happens when we detect that you were removed from an oauth org, should we remove you from any of the appropriate organizations?

If they are removed from oauth they will not authenticate right? So the authorization should not matter at that point.

[jaredscheib]

• [ ] make Public not settable via the API. see https://github.com/influxdata/chronograf/pull/2354/files#diff-6d6555cd1836442bec204208fd23bf61R178

[jaredscheib]

Ignore the above.

We realized that Mappings could cover the conceptual space of the Public/Private toggle on the Default org, so let's remove that toggle and instead include a Default mapping that is toggled on, to allow any authenticating user to become a role in the Default Org of Admin of it and be a SuperAdmin. That way the upgrade to 1.4.0 puts users in the exact same place as the app stands currently. (We may want to highlight this mapping somehow.)

[jaredscheib]

Current plan:

1. A fully permissive auth model, like what Chronograf is now, will come out of the box via a mapping of Scheme: *, Provider: *, Group (aka OAuth Org): * --> Chronograf Org: Default;
2. An admin of any organization can create or delete a mapping;
3. Group can be any auth group, such an an OAuth Org, *, and whatever is analogous in LDAP;
4. If you want some concept of "blocking", simply don't create a mapping(s) that would include those that you wish to block

Thoughts, @nhaugo ?

[lukevmorris]

After discussing with @desa, we're going to expose Mappings as its own resource, with a foreign key to the organization they belong to.

GET .../mappings/
PUT .../mappings
GET .../mappings/:id
PATCH .../mappings/:id

This will make it much easier to build the Providers tab in the Admin Chronograf section, as it's essentially operating on an array of mappings.

@goller Does this sound like a reasonable API change?

[goller]

Looks great ... but should be POST rather than PUT

On Jan 29, 2018, at 4:52 PM, lukevmorris [e-mail] wrote:

After discussing with @desa, we're going to expose Mappings as its own resource, with a foreign key to the organization they belong to.

GET .../mappings/
PUT .../mappings
GET .../mappings/:id
PATCH .../mappings/:id

This will make it much easier to build the Providers tab in the Admin Chronograf section, as it's essentially operating on an array of mappings.

@goller Does this sound like a reasonable API change?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[russorat]

👯 LGTM!