Class TeamContextResolver

Namespace

Tharga.Team.Service

Assembly

Tharga.Team.Service.dll

Resolves the team a request acts on, from the credential and an optional header. The single place that answers it — REST and MCP both call this rather than each working it out.

public sealed class TeamContextResolver

Inheritance

object

TeamContextResolver

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

An external caller never names a team in a parameter. A team API key is bound to one team and can be nothing else, so a parameter beside it would be a second source of truth for one question — they can disagree, and an API shaped to allow that is wrong even though the disagreement is refused.

A system key is bound to none, so it says which team it acts on behalf of in a header, and the team must have consented. What it may do there is the consented level, exactly as for a person reaching a team they do not belong to.

Consent for a key is the team's level, not a role match. A key holds no roles, so the question asked is whether the team consented at all. Worth stating plainly: a team that enables consent for its support staff thereby admits system keys too, at that same level.

Constructors

TeamContextResolver(ITeamService, IScopeRegistry, ITenantRoleService, IUserService, AccessLevel)

public TeamContextResolver(ITeamService teamService, IScopeRegistry scopeRegistry = null, ITenantRoleService tenantRoleService = null, IUserService userService = null, AccessLevel defaultConsentLevel = AccessLevel.Viewer)

Parameters

teamService ITeamService

scopeRegistry IScopeRegistry

tenantRoleService ITenantRoleService

userService IUserService

defaultConsentLevel AccessLevel

Methods

ResolveAsync(ClaimsPrincipal, string)

Resolves the team for principal, given the team named in the header (or null).

public Task<TeamContext> ResolveAsync(ClaimsPrincipal principal, string headerTeamKey)

Parameters

principal ClaimsPrincipal

headerTeamKey string

Returns

Task<TeamContext>

Remarks

The four cases, in the order they are decided:

1. A team-bound caller with a header naming a different team — refused. It is a contradiction, not a preference; ignoring it would leave the caller believing they asked for something they did not get.
2. A team-bound caller — its own team, with the scopes already on its claims.
3. No header — no team context. A system caller operates system-wide, which is what its system grants authorize.
4. A header — the named team, at its consented level, or refused if it has not consented.