Fixes #21987 - New UI for auth sources

[dhlavac]

This PR changes Administration for Authentication sources

Now is by default added External auth source to database. In setting and for running systems by migration.
Every authentication source have card and display number of users set up by authentication sources

Administer page for Authentication sources

Administer page for Authentication sources with no LDAPs

Drop-downs for External and LDAP authentication sources

[theforeman-bot]

Issues: #21987

[amirfefer]

Thanks @dhlavac, looks great!
I'd like to see this card view as a react component.
there are patternfly-react card and kebab components already.

When a pull request is still in progress, you can add [WIP] on the PR title.

[ohadlevy]

I too would love to see it in react, but maybe prior to that we should review the UX with @Rohoover as well? I could imagine different views (besides tables) that might be useful here?

[ares]

This is the outcome of discussion with @Rohoover, it's a midterm solution, until we have org/loc association per external hostgroup, until them we need table for ldap auth sources, as users need to create many of them in multiorg scenario. After that's done, auth sources should be cards only.

[ohadlevy]

On Wed, May 16, 2018 at 8:59 AM, Marek Hulán ***@***.***> wrote: This is the outcome of discussion with @Rohoover <https://github.com/Rohoover>, it's a midterm solution, until we have org/loc association per external hostgroup, until them we need table for ldap auth sources, as users need to create many of them in multiorg scenario. After that's done, auth sources should be cards only. Where can I find more information about your end goal? I find it hard to

understand what you are trying to achieve in the long term? (sorry, but just missing the user stories and dont understand how auth source, external hostgroups and multiorg comes together)

[ares]

I don't recall if the meeting back then was recorded. Here's the motivation, today we can setup mapping between external auth sources and user groups, user groups can have roles assigned. With external user groups mapping, administrators can manage permissions externally to Foreman, only by assigning user groups in their LDAP. This works fine for permissions but not for ogranizations and locations, which is our secondary authorization system. For that we added orgs/locs associations to ldap auth sources. When user account is created, it gets associated to orgs/locs the LDAP is assigned to.

The problem is that if I want to have single LDAP for multiple organizations, each use belonging to different one, the model does not fit. People workaround that by having multiple LDAP definitions for the same LDAP server but with different filter and organization assigned. That means easily >10 LDAP authsources in env with multiple orgs.

We started adding the same model to external auth source (using just REMOTE_USER) but in order to do it, we had to add API and UI for manipulating it's org/loc association. As part of that, @dhlavac adds UI for it. This is a temporary solution, where we'll still have table for ldap authsources (as there can be a lot of them because of ^) and cards for internal and external (both have single instance). Later we want to add org/loc association also to external user group which should dramatically decrease the number of LDAP auth sources defined here and at that point we'd like to convert the table to cards. So at the end, all auth source instances should be represented by card.

Hope that puts more light on the change. When @dhlavac started working on this, there were no cards implemented and patternfly roadmap was unclear about this. Since it was few months ago, I think we can revisit the decision. Though I'm not sure I'd block this PR because of that single card partial. It's not the crucial part of it. But I'd definitely support the effort that would follow right after this gets in, so that we'll get card implemented as a react component if @dhlavac agrees.

[dhlavac]

@ares PR is ready I hope. @ohadlevy @amirfefer If it isn't problem, for now I will let card component in erb. It's a midterm solution, until we have org/loc association per external hostgroup and then implement react component for cards.

[ares]

There seems to be several hound/rubocop issues, mind to rebase and fix them?

[ares]

rubocop failures, rebase would also be good (no conflicts)

[ares]

this needs to be rebased

[ares]

couple of new findings, please take a look

[dhlavac]

@ares Changes done

[dhlavac]

@ares Anything else what can I do on this PR ?

[mmoll]

@dhlavac please rebase :)
@ares any more comments?

[dhlavac]

@mmoll @ares rebased

[theforeman-bot]

@dhlavac, this pull request is currently not mergeable. Please rebase against the develop branch and push again.

If you have a remote called 'upstream' that points to this repository, you can do this by running:

    $ git pull --rebase upstream develop

---

This message was auto-generated by Foreman's prprocessor

[mmoll]

@dhlavac This needs a rebase :)

[dhlavac]

@mmoll I don't know if it is still planned to use this feature. @ares should I rebase that or close PR ?

[ezr-ondrej]

@dhlavac if you're not plannig to continue I was planning to take over. I do not know when I will get to it though.

[tbrisker]

closing in favor of #7206

[tbrisker]

Thanks for the effort here @dhlavac !