docs(sso): state what the OpenID Connect ID token check does and does not cover - #497
Merged
Merged
Conversation
… not cover Four points where sso-oidc.rst left a reader with the wrong expectation, in all seven languages. - The note that the JWT signature is not verified stops there, which reads as if the rest of the token were checked. The `iss`, `aud` and `exp` claims are not validated either: an expired token, one issued for a different client, and one from a different issuer are all accepted. That is the same trust argument the existing note makes about the transport, so it belongs in the same place. - "If the groups claim is not present, oic.default.groups is used" does not say which side of the line an empty array falls on. It counts as present: the default is not applied and the user ends up with no groups. Providers differ on whether a user in no group gets an empty array or no claim at all, so the two configurations behave differently. - The note that group values are used as they are explains that parent groups are not expanded, but not that the value becomes the search permission verbatim. A provider set to emit full group paths sends `/parent/child`, and documents tagged with the plain group name then match nothing. - The debug logger the troubleshooting section recommends writes the ID token claims, including the user's email address and group membership, to the log file. Say so, and say to put the level back afterwards.
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.
What
Four points in
sso-oidc.rstwhere the page left a reader with the wrong expectation. Allseven languages. Every statement was checked against the 15.8 implementation and confirmed
against a real OpenID provider.
The ID token check is narrower than the note implies
The existing note says the JWT signature is not cryptographically verified and stops there,
which reads as if the rest of the token were checked. It is not:
iss,audandexparenot validated either. An expired ID token, one issued for a different client, and one from a
different issuer all log the user in.
That matters to the decision the note is already asking the reader to make — whether the
channel to the token endpoint can be trusted — so it belongs in the same note.
An empty
groupsarray is not the same as an absent one"If the
groupsclaim is not present, the value ofoic.default.groupsis used" does not saywhich side of the line an empty array falls on. It counts as present: the default is not
applied and the user ends up with no groups at all.
This is not a corner case. Providers differ on what they send for a user who belongs to no
group — some omit the claim, some send
[]— so the same Fess configuration gives that userthe default groups on one provider and nothing on another.
The group value becomes the search permission verbatim
The note explains that nested groups are not expanded, but not what the value is used for. It
becomes the search permission as-is, so a provider configured to emit full group paths sends
/parent/child, and documents tagged with the plain group name then match nothing. Thesymptom is an empty result set for a user who looks correctly configured on both sides.
The recommended debug logger writes the ID token claims to the log
The troubleshooting section tells the reader to raise
org.codelibs.fess.sso.oicto DEBUG.That logs the claim set, which carries the user's email address and group membership, into a
file that gets read and copied around. Worth saying, along with putting the level back
afterwards.
Note
The behaviour on a provider error response is not covered here on purpose. That path is
being changed in a separate code change; a follow-up can document it once that lands.