RFD: https://github.com/SUSE/rancher-architecture/pull/55
Switch from
- single auth config enable/disable, single auth provider log in
To
- manage/CRUD multiple auth configs and their enabled/disabled state, multiple auth provider log in
Details
- prime only feature
- terminology
- TBD (UX) Currently we show a
Auth Provider section and allow user to select and configure one. Should we change terminology to Auth Configs. This sets us up better for when a single auth config contains different auth providers (provider for idp, provider for search)
- auth config management
- list auth configs
- doesn't have to be a list!
- create/edit auth config
- configure human readable name (for button)
- configure human readable description
- TBD (BE): prop for description (match UI general description annotation?)
- auth config actions
- delete auth config
- log in
/v1-public/authproviders returns enabled auth providers (it's a different structure to authconfig)
- authprovers id links to the auth configs metedata.name (though users can't fetch authConfigs at this stage)
- authprovider object contains both human name and description from authconfig
- allow user to choose auth config to log in via
- display
log in via 'human name' instead of log in via 'type'
- TBD (UX) : display description in tooltip?
- TBD (BE): post also needs updating with a reference to the ID
- Membership management
- When showing bindings we always have access to the backing principle, so users see the human name, avatar, etc
- When showing principals it should be clear which auth config they come from, and possibly also the ldp (provider) that it is. This is insightful but also avoids same name different provider problems
<provider type> / <auth config human name> / <type user / group / org> / <principle human name>
- OIDC / staging / team / terrys
- OIDC / production / team / terrys
Possible breakages
- principle ids change from
<provider>_<type>://<id> to <provider user provided name>_<type>://<id>. I think this only affects the model
- the type of an authconfig shouldn't come from the id, but from the _type
- this needs to pass through a translation layer, hopefully just removing the
Config suffix
- the type pf a /v1-public/authprovider shouldn't come from the id, but the type
- this needs to pass through a translation layer, hopefully just removing the
Provider suffix
Linking everything together
- /v1-public/authproviders id --> /v1/management.cattle.io.authconfig metadata.name | id
- /v1-public/authproviders type exists
- examples
- "type": "githubProvider"
- we (UI) just need to convert that to our concept of type
- /v1/management.cattle.io.authconfig type exists
- examples
- "_type": "activeDirectoryConfig",
- "_type": "azureADConfig",
- "_type": "githubConfig",
- we (UI) just need to convert that to our concept of type
- current auth config metadata.name
x matches authproviders <x>Provider and auth config _type <x>Config
RFD: https://github.com/SUSE/rancher-architecture/pull/55
Switch from
To
Details
Auth Providersection and allow user to select and configure one. Should we change terminology toAuth Configs. This sets us up better for when a single auth config contains different auth providers (provider for idp, provider for search)/v1-public/authprovidersreturns enabled auth providers (it's a different structure to authconfig)log in via 'human name'instead oflog in via 'type'<provider type> / <auth config human name> / <type user / group / org> / <principle human name>Possible breakages
<provider>_<type>://<id>to<provider user provided name>_<type>://<id>. I think this only affects the modelproviderfield insteadConfigsuffixProvidersuffixLinking everything together
- "type": "githubProvider"
xmatches authproviders<x>Providerand auth config _type<x>Config