This doc is meant to serve as the "one doc to rule them all" for Pinniped community meetings and open discussions. :::info :information_source: Community Meeting Details ::: Community meetings are held every first and third Thursday of each month at 9AM PT(Convert to your time zone): Zoom Link Join our Google Group to get updates on the project and invites to community meetings. Previous community meeting recordings: Pinniped YouTube Playlist Need help or have an issue to discuss with the team? Add your item to Discussion Topics for the next meeting's agenda. :point_down:

Okta IDP Configuration The OIDC client must be configured to allow password grant bt creating a "Native App" in the Okta UI. Additionally, it must be configured to allow refresh by checking the "Refresh Token" box on the App's configuration. There is another option on the App's configuration to either "Rotate token after every use" or "Use persistent token" (the default). Refresh token lifetime is configurable in the "Authorization Server" settings, but not on the client itself. Perform an Authorization curl -X POST https://dev-475662.okta.com/oauth2/default/v1/token \

Problem Statement The Pinniped Supervisor is an OIDC Issuer. It supports the OIDC offline_access scope with the refresh_token grant type as a way to refresh a user's tokens without requiring user interaction. Upon logging in to pinniped, users are granted a refresh token that is valid for 9 hours. Currently Pinniped users' initial authentication is with the external identity provider, but the Supervisor does not verify user information with the external IDP when refreshing tokens. It only checks whether it recognizes the token and whether it is within the 9 hours. When the refresh flow occurs, the supervisor should verify that the user still exists in the upstream identity provider and check for any changes in group membership. Use Cases Password Change

Note: This doc is a Work in Progress 👷‍️🚧👷‍♀️ Use cases for multiple identity providers (IDPs) Imagine you are an IT administrator at a large company who is responsible for creating and handing out fleets of Kubernetes clusters. You have decided to use the Pinniped Supervisor to control authentication to those clusters. Each pool of clusters should allow authentication from a distinct pool of users, so each pool of clusters will share a FederationDomain as their source of users. Therefore, you like to have configuration knobs which help you craft a unique pool of users for each FederationDomain. Some examples of when you might like to employ multiple IDPs could be: You would like to create a pool of clusters for each development team, and ensure that members of any team are only allowed to authenticate to their own clusters.

Goal We would like to come up with some user stories for Pinniped Supervisor LDAP upstream IDP support, reasonably sequenced for iterative development. Design Considerations Open Questions: What does our LDAP config look like? (See below for detailed notes.) LDAPIdentityProvider CRD with:

Introduction This document describes a design to solve pinniped/#668 (Support for OIDC logins on hosts without a local web browser ("jump host")) by adding support for response_mode=form_post in the Pinniped Supervisor. What is response_mode=form_post? The response_mode parameter is defined in OAuth 2.0 Multiple Response Type Encoding Practices. It is a counterpart to response_type which "informs the Authorization Server of the mechanism to be used for returning Authorization Response parameters from the Authorization Endpoint". The current behavior in Pinniped corresponds to response_mode=query, where the response is returned via an HTTP redirect with URL query parameters. The meaning of response_mode=form_post is defined by OAuth 2.0 Form Post Response Mode. Instead of an HTTP redirect, the response parameters such as authorization code, state, and granted scopes are "encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client". There is also a well known field in the OIDC discovery document to advertise supported response modes (response_modes_supported defined in OpenID Connect Discovery 1.0 incorporating errata set 1).

This document is an informal design document for API changes related to the new "impersonation proxy" functionality of the Pinniped concierge component. Goals Allow everything to work out of the box in as many cases as possible Eventually support full configuration of all proxy-related behavior Deprecate and later eliminate the singleton CredentialIssuer resource. Non-Goals

Moved to https://github.com/vmware-tanzu/pinniped/pull/387 for review.