mantis-toboggan-md
commented
4 years ago The 11 authentication service providers in the existing UI can be roughly grouped into 4 categories:
- LDAP/Active Directory
- SAML
- Walkthrough another website
- Azure Active Directory
The first 3 of these types can share a few components :
- LDAP input fields
- required fields
- schema customization ('users' and 'groups' sections)
- SAML fields
- 'Step' component for walkthrough of other websites
- Multiline input with 'paste from file' button
LDAP/Active Directory
(FreeIPA, OpenLDAP, Active Directory)
All LDAP types and Active Directory feature the same set of fields and can share a component with the following content
| Label | Component | Required? | Default |
|---|---|---|---|
| Hostname/IP | LabeledInput | yes | |
| Server Connection Timeout | UnitInput (milliseconds) | yes | |
| Port | LabeledInput (integer) | yes | 389 / 636 for TLS |
| TLS | Checkbox | no | no (unchecked) |
| CA crt* | LabeledInput (multiline) | yes | |
| Service Account Distinguished Name** | LabeledInput | yes | |
| Service Account Password** | LabeledInput (hidden text) | yes | |
| User Search Base | LabeledInput | yes | |
| Group Search Base | LabeledInput | no |
* only show if TLS=true ** The Ember UI has an explanation above these fields:
Rancher needs a service account that has (read-only) access to all of the domains that will be able to login, so that we can determine what groups a user is a member of when they make a request with an API key.
In addition to these mostly-required fields, there's a section for customizing the schema if the LDAP server in question is non-standard. These fields can all use a LabeledInput
Users
| Label | Default | AD default | ||||
|---|---|---|---|---|---|---|
| Object Class | inetOrgPerson | person | ||||
| Username Attribute | cn | name | ||||
| Login Attribute | uid | sAMAccountName | ||||
| User Member Attribute | memberOf | |||||
| Search Attribute | uid | sn | givenName | sAMAccountName | sn | givenName |
| Search Filter | ||||||
| User Enabled Attribute | userAccountControl | |||||
| Disabled Status Bitmask | 2 |
Groups
| Label | Default | AD default |
|---|---|---|
| Object Class | groupOfNames | group |
| Name Attribute | cn | name |
| Group Member User Attribute | entryDN | distinguishedName |
| Search Attribute | cn | sAMAccountName |
| Search Filter | ||
| Group Member Mapping Attribute | member | member |
| Group DN Attribute | entryDN | distinguishedName |
Additionally, groups includes Nested Group Membership with two options:
- "Search only direct group memberships"
- "Search direct and nested group memberships"
SAML
(Ping, KeyCloak, AD FS, Okta, Shibboleth‡)
| These types have some individualized configuration required within the SAML client, but all require the following inputs on the Rancher UI side | Label | Component | Required? | Default |
|---|---|---|---|---|
| Display Name Field | LabeledInput | Yes | ||
| User Name Field | LabeledInput | Yes | ||
| UID Field | LabeledInput | Yes | ||
| Groups Field | LabeledInput | Yes | ||
| Rancher API Host | LabeledInput | Yes | \<your Rancher API url> | |
| Private Key | Multiline Input with Paste-from-file | Yes | ||
| CA crt | Multiline Input with Paste-from-file | Yes | ||
| Metadata XML | Multiline Input with Paste-from-file | Yes |
‡ Shibboleth can be configured with an OpenLDAP backend, and if so, should also show the LDAP-type inputs. I would probably hide that section by default and include:
| Label | Component | Required? | Default |
|---|---|---|---|
| OpenLDAP backend? | Checkbox | No | No |
GitHub and Google OAuth
Most of the setup occurs on GitHub and Google websites, with steps listed out in Ember UI. Currently, each of these pages is styled slightly differently:
I think they should both use some sort of Step component for consistent styling.
Azure AD
This provider is really off doing its own thing in terms of the Ember UI, no component to share with the other types.
lvuch
deniseschannon
Research on which fields could be used to create re-usable components.