Identity: the glue, not the guards¶

Underneath sits identity: DigiD, eHerkenning and eIDAS, wired in over SAML or OIDC, sometimes through ADFS or Azure AD on the supplier side. The providers are solid; the weak points are in the glue around them, the session handling, the assertion validation, and the join between a login and the thing it authorises.

Follow inloggen.ankh-morpork.example. A click on “Inloggen met DigiD” posts a SAML AuthnRequest to DigiD:

AssertionConsumerServiceURL = https://inloggen.ankh-morpork.example/acs
Issuer                      = ankh-morpork      (the connecting service, named in the metadata)

DigiD authenticates the resident and returns an assertion by artifact binding to that ACS. Two questions decide whether the glue holds. Does the service consuming the assertion check its signature, audience and freshness, or take a replayed or retargeted one? And once the assertion is in, does the session it mints stay bound to the same bsn all the way through to the case it opens? The DigiD-normenkader audits the first every year, which raises the baseline and names exactly which controls were checked. What it does not reach is the second, the authorisation made several steps downstream of the login, and that is where the untested weaknesses sit.