Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Script to manage OIDC client metadata #51

Open
mar235av opened this issue Jun 10, 2024 · 1 comment
Open

Script to manage OIDC client metadata #51

mar235av opened this issue Jun 10, 2024 · 1 comment
Assignees

Comments

@mar235av
Copy link
Contributor

Currently, the metadata for all OIDC clients is a single monolithic file in JSON format stored on each IdP server. There are several problems with this situation:

  1. Any (necessarily manual) edit to the file risks corrupting the file which would break all OIDC integrations.
  2. The client secrets are stored in the file, so any review or edit exposes these client secrets.
  3. Combining secret and non-secret information is bad practice and would make containerization difficult.

Desired:

  1. Create new files that hold the metadata for each client in a separate file.
  2. Remove the client secrets from those files and store them in a separate location.
  3. Write a script that combines the secrets and the non-secret metadata into the single file that Shibboleth needs.
  4. The script should perform basic validation on the generated file: (a) require valid JSON; (b) require a list of objects, each of which is a set of key/value pairs; (c) warn on unknown key; (d) require valid data type for each value depending on its key.

The eventual vision is to store at least the metadata in the SPRegistry database (with lack of clarity on how the secrets should be stored), so the design should support migration to that future state.

@mar235av
Copy link
Contributor Author

Deferred due to lack of resources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants