The system said the user exists. The identity provider said they are verified. But the federation refused them. Why? Because the user config is dependent.
Identity federation user config dependent means access relies not only on the identity assertion from an IdP (Identity Provider), but also on local configuration inside the relying service or application. The IdP hands over a token, but the consuming app checks a local record before granting access. If the local config is missing, outdated, or set to deny, authentication breaks.
This happens in SAML, OpenID Connect, and custom federation setups. You can accept tokens from AWS Cognito, Azure AD, Okta, or Ping Identity, but still need app-side user profiles or role mappings. The federation binds the two sources: the external identity and the internal permissions. Both must align.
Experienced teams use user-config-dependent federation to impose fine-grained control. It allows revoking access without touching the central IdP, enforcing local policy rules independent of global identity data. But it increases maintenance cost. Every provisioned user must have an accurate config in the local system. Drift between IdP attributes and local state is the common failure point.