Snowflake Security and SAML

There’s been a bit of stories about Snowflake recently; both from users who are recovering from the fact that Snowflake had no velocity limits on their wide open user data buckets, companies who are upset about their lack of meaningful MFA Controls, and then Snowflake reporting that they are now going to force MFA controls on all user accounts.

If I’m an administrator at a larger organization, and I’m adding applications to my organization’s SaaS footprint, the baseline is that SSO is a hard requirement. If your team doesn’t have the cash to spend for SSO on their product, then you better build and maintain your own solution, because you have a better chance of winning the lottery than me approving that purchase or allowing our internal or customer data outside of the network: I likely have a SAML implementation – be it EntraID, Okta, OneLogin, or something else – and I’m already enforcing MFA and trusted devices for all of our federation.

What SAML doesn’t have, is the concept of an Sp-initiated request for an “MFA event.”

Let’s say I’m an application that is in my corporate environment that controls reimbursement. I want to have the application request – to the Identity Provider – to have the Identity Provider re-validate the user’s factors…not the password, but, ideally, their second factor. The IdP would validate the second factor, then sign and re-send the event back to the application.

Then I, as the Application Author, don’t have to worry about second factors. I don’t have to support second factors…because I don’t want the risk from storing, managing, or handling those items.

I’ll shit on Snowflake later for not having meaningful controls on their customer buckets, because, it’s twenty-fucking-twenty-four.