Update ns key discovery to follow openid-style lookups #583
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jhiemstrawisc
force-pushed
the
issue-111
branch
from
ff41f86 to
ecd6073
Compare
|
Closes #111 |
jhiemstrawisc
force-pushed
the
issue-111
branch
from
faba057 to
8b8eed7
Compare
|
I'm holding off reviewing this PR as there are major changes of registry API done in #613 which will cause significant merge conflict with this PR, and with #613 merged in, you might need also to downgrade the API version to be compatible, but I like the idea to have a conformed way to do the look up. Let's talk about how to proceed @jhiemstrawisc |
|
@haoming29, sounds good. Let's focus on getting #613 in, and then I can revisit this to see what still makes sense. |
haoming29
reviewed
Jan 12, 2024
|
Hey @jhiemstrawisc How are we doing here? It feels like there are lots of related work done to the registry that causes considerable amount of merge conflict to this PR, and I thought it'd be beneficial to have it closed soon. |
jhiemstrawisc
force-pushed
the
issue-111
branch
2 times, most recently
from
3374afa to
fd92230
Compare
haoming29
reviewed
Jan 31, 2024
haoming29
approved these changes
Jan 31, 2024
Previously, namespace keys were fetched by hardcoding the issuer jwks relative to the namespace. Now we follow openid-style lookups by fetching the JSON located at <registry url>/api/v2.0/registry/metadata/<namespace>/.well-known/namespace-configuration and following the URL associated with the `jwks_uri` key. Currently this is still the same key path in all instances that I'm aware of, but in theory this could be expanded to point to other locations. The architecture of this PR is that a GET request to the namespace-configuration url mentioned above should dynamically generate the `jwks_uri` key with associated value. The value is used throughout and assigned the issuer URL in various places where we need to create a token on behalf of the namespace.
Previously I wasn't using the term "issuer" correctly -- really, we should be thinking about the issuer as the endpoint against which we perform openID-configuration lookup to find the issuer key. That is, for registry.com and ns prefix /foo/bar, the issuer is registry.com/api/v1.0/registry/foo/bar. We take that endpoint and grab the JSON hosted at registry.com/api/v1.0/registry/foo/bar/.well-known/openid-configuration. From there, most Pelican services will point to the key hosted at registry.com/api/v1.0/registry/foo/bar/.well-known/issuer.jwks.
jhiemstrawisc
force-pushed
the
issue-111
branch
from
22b79fe to
3ae6ae6
Compare
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, namespace keys were fetched by hardcoding the issuer jwks relative to the namespace.
Now we conform to openid-style lookups by fetching the JSON located at
/api/v2.0/registry/metadata//.well-known/namespace-configuration
and following the URL associated with the
jwks_urikey. Currently this is still the same key pathin all instances that I'm aware of, but in theory this could be expanded to point to other locations.
We can also expand this namespace-configuration JSON to include additional information as needed.
The architecture of this PR is that a GET request to the namespace-configuration url mentioned above
should dynamically generate the JSON with
jwks_urikey and associated value. The value is used throughoutand assigned the issuer URL in various places where we need to create a token on behalf of themnamespace.