Make it easier to configure my IDP by having something better than a log statement to tell me what my upstream IDP said about me
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 739
- Forks
- 85
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 1
Description
Is your feature request related to a problem? Please describe.
- I've configured an upstream IDP (in my case, OIDC), and now I want to know what my upstream IDP says about me (e.g., what groups am I in? what is my username? what are my other claims (in the case of OIDC) or attributes (in the case of LDAP)? etc.)
- Right now, I do this for OIDC via looking at the
plog.LevelAlllog statement, which is kinda cumbersome (although I am grateful that the log statement is there): https://github.com/vmware-tanzu/pinniped/blob/ca2ee26c8641de24f9cb65399dfe275ae1aadfcb/internal/upstreamoidc/upstreamoidc.go#L334
Describe the solution you'd like
- @enj said ["I would like to have an API that could be used via the CLI to aid in a user determining their upstream IDP said about them (generically for all IDPs)"|https://kubernetes.slack.com/archives/C01BW364RJA/p1639064773170300?thread_ts=1639059009.168900&cid=C01BW364RJA]
- That solution sounds like it could fit into a broader "make Pinniped easier to debug" story, which is appealing to me
Describe alternatives you've considered
- Uh, the logging thing above, and not much else
Are you considering submitting a PR for this feature?
- How will this project improvement be tested?
TBD - How does this change the current architecture?
TBD - How will this change be backwards compatible?
TBD - How will this feature be documented?
TBD
Additional context
This feature came from this discussion: https://kubernetes.slack.com/archives/C01BW364RJA/p1639059009168900
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with internal/upstreamoidc/upstreamoidc.go at the referenced plog.LevelAll log statement and review the linked discussion about a CLI/API. Define a generic way to expose upstream IDP claims or attributes for OIDC and LDAP, then establish how the behavior should be tested and documented. Done means users can inspect what their upstream IDP reported without relying on logs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authentication, cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100