Skip to content

SubjectTypeConverterExtensions Class

Comparing a session against the end users a client named.

C#
public static class SubjectTypeConverterExtensions

Inheritance System.Object → SubjectTypeConverterExtensions

Methods

SubjectTypeConverterExtensions.Names(this ISubjectTypeConverter, AuthSession, IReadOnlyCollection<string>, ClientInfo) Method

Whether this session belongs to one of the end users named, as the client spells them.

C#
public static bool Names(this Abblix.Oidc.Server.Features.PairwiseIdentifiers.ISubjectTypeConverter converter, Abblix.Oidc.Server.Features.UserAuthentication.AuthSession session, System.Collections.Generic.IReadOnlyCollection<string> subjects, Abblix.Oidc.Server.Features.ClientInformation.ClientInfo clientInfo);

Parameters

converter ISubjectTypeConverter

Seals the session's subject the way this client sees it.

session AuthSession

The session to judge.

subjects System.Collections.Generic.IReadOnlyCollection<System.String>

The end users the request will accept. Empty accepts nobody.

clientInfo ClientInfo

The client whose spelling of a subject is in force.

Returns

System.Boolean

Remarks

OpenID Connect Core 1.0 Section 3.1.2.2 requires this wherever a request names an end user: the server "MUST NOT reply with an ID Token or Access Token for a different user, even if they have an active session". Every endpoint accepting such a name needs the same comparison, and one that wrote its own would have to rediscover both properties below.

The session is converted forward rather than the name opened, because only the forward direction answers for a client whose sector moved since the name was minted: opening would fail, while sealing produces the pseudonym that client would receive today and compares it against what was sent.

Neither direction is total. Sealing needs pairwise settings the deployment may not have configured, and a client registered as pairwise without them makes the converter throw. That is a configuration fault rather than an answer about this end user, so it is reported as no match: the caller refuses this session instead of faulting every request that merely named somebody.