Skip to content

Support Multiple Auth Providers #17295

@richard-cox

Description

@richard-cox

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
      • enable / disable
    • 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    QA/dev-automationIssues that engineers have written automation around so QA doesn't have look at thisRFDarea/authAuthentication and RBACkind/enhancement

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions