Repository navigation
feat(federation)!: honour or refuse an automatically registered RP's subject_type - #647
Merged
Merged
Conversation
…subject_type An automatically registered Relying Party's subject_type (OpenID Connect Dynamic Client Registration 1.0 section 2) used to be ignored, so one asking for pairwise subjects got public ones. Automatic registration now records the subject_type the Relying Party's resolved metadata names (after its superiors' metadata policy), or the server's default when it names none, and refuses one the server doesn't issue: the Relying Party gets invalid_client and OnResolutionFailure hears why. A pairwise Relying Party's sector is the single https host its redirect URIs share, derived as for any other client, so redirect URIs on several hosts fail its registration. sector_identifier_uri isn't fetched in this release, so a pairwise Relying Party publishing one is refused rather than given a sector other than the one it named; a public one's is ignored. federation.AutomaticRegistrationConfig gains SubjectTypes and DefaultSubjectType, which server.New sets from Config.Subjects through the same helper discovery's subject_types_supported uses, so what is advertised is what registration accepts. Left zero, they mean public only. federation.OpenIDRelyingPartyMetadata gains SubjectType for an RP publishing its own metadata. BREAKING CHANGE: an automatically registered Relying Party whose metadata asks for a subject_type the server doesn't issue (pairwise, while the server issues only public subjects) is no longer registered, rather than given public subjects. A pairwise one must have redirect URIs on one https host and no sector_identifier_uri. See UPGRADING.md for v0.55.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
An automatically registered Relying Party's
subject_typemetadata (OpenID Connect Dynamic Client Registration 1.0 §2) was ignored, so one asking for pairwise subjects silently got public ones. This is the federation part of pairwise subject support.Behaviour
subject_typeits resolved metadata names (after superiors'metadata_policy), or the server's default when it names none.subject_typethe server doesn't issue (e.g. pairwise from a public-only server, or public underSubjectTypesPairwiseOnly), or an unknown value, fails the registration: the RP getsinvalid_client, andOnResolutionFailurehears why.sector_identifier_uriisn't fetched in this release: a pairwise RP publishing one is refused rather than given a sector other than the one it named (so supporting it later won't change anyone'ssub); a public RP's is ignored.API
federation.AutomaticRegistrationConfig.SubjectTypesand.DefaultSubjectType.server.Newsets both fromConfig.Subjectsthrough the same helper that buildssubject_types_supported, so discovery and registration agree. Zero means public only.federation.OpenIDRelyingPartyMetadata.SubjectType, for an RP publishing its own metadata.Breaking: an RP asking for a subject type the server doesn't issue is now refused instead of registered with public subjects. UPGRADING.md has a v0.55.0 section.
Tests: metadata variants, a superior's policy forcing pairwise, conflicts with the server's types, sector rules, a stable result across registrations, config validation, and the wiring through
server.New(registration,ClientSubjectand discovery). All 12 mutants of the new logic were caught.🤖 Generated with Claude Code