Identity federation lets Snowflake trust an external identity provider (IdP) for authentication. Instead of managing separate credentials, users authenticate with systems like Okta, Azure AD, or PingFederate. Federation streamlines access across tools, enforces enterprise-grade policies, and centralizes identity. In Snowflake, this means a direct mapping from your IdP roles to Snowflake roles without manual provisioning.
Data Masking in Snowflake
Data masking restricts exposure of sensitive fields at query time. Using masking policies, you define rules that transform or hide data based on a user’s role, session context, or attributes passed via the federation link. A Social Security Number can be fully visible to an analyst with clearance, partially masked for a support rep, and entirely hidden for others. The rules live in Snowflake’s metadata and execute automatically.
Combining Identity Federation and Data Masking
When federation and masking work together, security becomes dynamic. The IdP asserts identity and attributes—such as department, clearance level, or geographic region—directly into Snowflake’s session. Masking policies read those attributes in real time and decide if the data should be returned unaltered, masked, or blocked. There is no manual switch to flip; the system enforces the rules at scale.