Uploaded image for project: 'OpenShift Authentication'
  1. OpenShift Authentication
  2. AUTH-8

[Auth]Consume group membership information from an identity provider

    XMLWordPrintable

Details

    • Consume group membership information from an identity provider
    • 21
    • Done
    • 100
    • 100% 100%

    Description

      Summary (PM+lead)

      At login time, some identity providers (notably OIDC and RequestHeader) can provide group membership information for the authenticating user. That group membership should be able to be used within OpenShift.

      Motivation (PM+lead)

      TODO(Anand)

      Goals (lead)

      Non-Goals (lead)

      Deliverables

      Proposal (lead)

      --- new proposal

      • should be made clear within an enhancement

      --- old proposal

      • Persist group data obtained at login in the API access token object
      • allows admins to set a max lifetime on a token, after which the group membership must be revalidated by logging in and obtaining a new token
      • the group membership doesn't apply to other API tokens
      • allows identity providers to provide different group membership depending on login method
      • avoids write contention on Group API objects
      • allows admins to continue using Group API objects for "local" groups
      • avoids the need to add source info for every member in a Group API object
      • Make the identity-provider group name directly to an OpenShift group name
      • a mapping can be added later if needed
      • Enhance the following identity providers to consume group info:
      • OIDC (via configurable claims(s), containing string or string array data)
      • RequestHeader (via configurable and optionally repeated header(s) containing group names)
      • Remote basic auth (via "groups" field containing string array data)

      User Stories (PM)

      TODO(Anand)

      Dependencies (internal and external, lead)

      Previous Work (lead)

      • Reference:

       

      Open questions (lead)

      1. What limitations should be placed on group names obtained from an identity provider?
      2. Should `system:...` groups be allowed?

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

       

      Attachments

        There are no Sub-Tasks for this issue.

        Activity

          People

            slaznick@redhat.com Stanislav Laznicka
            openshift_jira_bot OpenShift Jira Bot
            Xingxing Xia Xingxing Xia
            Votes:
            18 Vote for this issue
            Watchers:
            48 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: