Callers are identified by IIS using Windows integrated authentication;
SAIF.Agency.Api contains no authentication code of its own. Authorization is
enforced by [SaifAuthorize] attributes, but only on two of the three
controllers: AgenciesController and AgentsController require the
AgencyRead role, the agency contact update additionally requires
AgencyContactWrite, and AppointmentsController — including its POST —
carries no authorization construct at all.
IIS site configuration; <authentication mode="Windows" /> in Web.config with <anonymousAuthentication enabled="false" /> in the site's system.webServer/security section
Identity type
WindowsIdentity, projected onto AgencyCaller by AgencyApiBase
Configured in
src/SAIF.Agency.Api/Web.config
Anonymous access
Denied
A caller proves identity before any managed code in this repository runs: IIS
negotiates Windows authentication, and a request that fails to authenticate is
rejected by the server with 401 Unauthorized without reaching the routing
stage. AgencyApiBase reads RequestContext.Principal.Identity on every
request and resolves it into an AgencyCaller record, which supplies the
CHANGED_BY value written by the contact update. Consumers therefore call as
their own service identity — the agency portal's application pool account, the
SAIF.Claims.Intake application pool account, and the scheduled task account
that runs SAIF.Policy.RenewalNotice — not as an end user.
There is no data-level restriction anywhere in the service: a caller holding
AgencyRead can read every agency, not only the agency they belong to.
On success the audit row carries the caller; if the identity cannot be resolved the service raises AgencyValidationException and the caller receives 400 Bad Request rather than an unattributed write.