Single Sign-On (SSO) in Snowflake

Other Meetups and Events to check out:

• Snowflake events
• DataLakeHouse.io events
• Carolina’s Snowflake Meetup Group

Transcript of the Meetup video:
Welcome to another Carolina Snowflake meetup group session. We’ll be talking about single sign (SSO) on for Snowflake today. And this is just really an introductory presentation on SSO for Snowflake. 

So just to kind of jump into it a little bit to kind of our standard slides talking about our previous meetups, we do record all of our presentations and we put them up on our YouTube channel. And if there’s any code that we write, we put that on our GitHub channel. 

So anyone who wants to try out anything that we’ve done during these meetups, can do. So, just a real quick presentation today on SSO. What is it? 

Some use cases as we particularly look at SSO with Snowflake. Things to consider and talking about, do we actually need SSO for Snowflake? We’ll wrap up.

So for some of the folks here, you might be new to Snowflake, or you might be a veteran to Snowflake, but for those that are new or just either starting your journey or will be in the very near future, of course, welcome. 

And we hope that everyone does jump on to Snowflake. Naturally, we’re biased. We love Snowflake. We’ve been leveraging Snowflake for many, many years. And really why we and anyone else that leverages Snowflake, what we all have come to love and really take advantage of with Snowflake is when everything is running in the cloud and Snowflake doesn’t care, where is your data coming from on prem cloud sources, third party data, and landing that data within Snowflake. 

And naturally, you have various audiences that will be consuming the data. Some of those audiences want the data closer to its raw. Format from the source. And other audiences are going to want that data curated a little bit more into data warehouses, data mart for enterprise type reporting, and everything in between. 

And Snowflake really handles all those different users taking advantage of really just charging you for what you use at the end of the day. So very efficient use of technology and very powerful as well. 

All right, so just jumping into SSO. This might be familiar to some people, might not be familiar to everyone, but we probably use it every day as we interact with the World Wide Web, especially within our enterprise organization, whether we know it or not. 

And so really, it’s an authentication protocol that happens when you log into an application. Your login is actually going to a centralized identity provider to authenticate, but also to identify the authorization or the access that you have to an application. 

And the great thing about it is it allows you then once you sign in to one application, the fact that you sign into the application gives any other applications you need to sign into. It gives them the acknowledgement that you’ve already signed in, you’ve already been authenticated as a user, and then it should allow you to just simply open and have access to the other applications.

We see this a lot in really enterprise organizations, but it can actually take place in smaller organizations. And we see it all across the web again, whether you know it or not. We’re going to show you some examples of it.

So turning SSO on or enabling it for your app locations, it creates a certain level of convenience. It provides a really smooth. Interface and experience for your, for your users and your platform increases adoption rates of the software that you’re accessing, whether you’re a provider or user, it’s going to increase the flow that you have.

And then of course, security is almost unmatched. By providing a centralized place to store your users, the authentication and also the authorization concepts, it really does create a great layer in your enterprise or your platform for security and it also prevents having other parts of an organization.

Try to develop one off custom security concepts for handling log in and access to your platform to the applications that you use. And I talked about identity providers and one that you might be familiar with if you’ve been in technology space or worked in organizations for a while is Microsoft.

They’ve had this concept called Active Directory for a very long time. Probably the most popular kind of centralized user repository, especially in enterprise organizations, or when I say enterprise organizations, think of any company that’s out there that you might work for now or you might have worked for in the past.

And Microsoft Active Directory was traditionally an on premise product, kind of paired nicely with the Microsoft Office suites and things like that. But over the last decade as things have moved into the cloud, as we say, so things are more decentralized.

There’s a lot of applications that customers license or they subscribe to that are in the cloud, meaning they don’t have to install any software on premise to gain use and functionality of that software of those platforms.

So with the clouds come on. Increased number of vendors that basically are taking on the same type of feature capability that the on premise Microsoft Active Directory User repository took on. And now they’re able to provide different types of features that really accommodate cloud based software, subscription based software that you do not install into your on premise data center, things like that.

So these are just some of the common ones that we see as we’re working with SSO within Snowflake and other products that we’ve worked with in the past. So you’ve got Octa, which kind of has become the leader, if you will, in identity management over the last few years.

They have a great platform, we’ll talk about that a little bit off Zero, which was a little bit more independent identity provider who was actually acquired by a de not too long ago. Microsoft has taken their historically on premise Active Directory and brought that into the cloud many, many years ago.

One login, there’s a few more that we’re not listening here. And then of course, even though we talked about not having shadow it, there is the ability to create your own single sign on capability with an organization.

We’ve seen some government agencies do this and one type of SSO framework is called SAML. And we’ll actually talk about that here in a few minutes. So this is a little bit more background on SSO as we kind of apply it to Snowflake.

So we’ve talked about what it is, we’ve talked about some vendors that help enable it, and then let’s just talk about a few of the types that we have with SSO. So the two most popular types of single sign on are really referred to the protocols that enable them.

So one is SAML, like I mentioned before, and another one is Open ID and they both provide security. Encryption end to end, but they use two different formats. So you’ll see, SAML uses more of an XML structure and Open ID uses more of a JSON structure, actually referred to as a JWT.

So it’s more of a token based encryption that you can pass along from website to website, in essence in your web browser as you’re accessing these different applications. And again, when we talk about different applications, we’re talking Snowflake, but you could also think the same thing would apply to maybe other popular platforms that are on the web, such as Salesforce.com HubSpot, maybe your company uses some HR tool like Seridian and things of that nature.

So those are all platforms that would allow your organization to be SSO enabled for security and again, centralizing your users to have access to those applications. So we did mention Snowflake, and at least on our review and our implementation of SSO with Snowflake, open ID doesn’t really seem to be one of the key protocols that’s out there for Snowflake.

So when you do read the documentation and you look at Federated Security and SSO integration with some of the providers I mentioned before, you typically are going to see the SAML protocol, which is great.

I mean, SAML has been along for here for a while. It’s a great protocol, it’s very secure and it actually allows a lot of additional customization where you can do some advanced SAML configurations. And I think that’s why it’s one of the primary SSO integrations for Snowflake.

So I want to give some attribution to a really great site that we like to look at as it relates to. Technical architectures. Our friends over at Bite by Go where we love the diagram, and they’ve got a wonderful five minute YouTube video that walks you through end to end the entire process and flow of SSO.

And you can really apply this as it relates to Snowflake because the same concept aligns. And so I won’t go into great detail here, but you can see the identity providers down the bottom, right? If you’re interested, you can always ask your company which or your infrastructure team which identity provider your company uses.

And then of course, the interactions are all done behind the scenes. So we really want to get into technical details of how this works. This will be a great diagram, but most of us aren’t concerned about the level of detail. 

So if we can’t move over to talking about how do we set up SSO within Snowflake. And again, this is not a technical deep dive into single sign on and Snowflake, it’s just a high level overview to give you guys some of our thoughts and opinions. 

We’ve done this several dozens of times, working with customers implementing single sign on within Snowflake. And one of the platforms we do see out there often is Okta, we do see off. We work quite a bit in one login, but I would say primarily what we’ve seen and worked on is Okta. 

They actually have a very simple integration for going in and configuring what they call an application. So every platform that you want your users to single sign on into, you would go into your identity provider. 

You would either be able to pick the platform, like Okta actually has a platform selection for Snowflake, or if you’re using another provider like off zero or one login, you basically just have to customize and create that application from scratch. 

And at that point you do some provisioning, pretty much a decent walkthrough process of going into Snowflake, running a few commands, going back into the identity provider, entering those commands and we’ll talk in a few minutes about one of the biggest things is just the testing. 

If you think about what’s going to take take the most time, it’s really the amount of testing that you have to go through. So we’ve actually written a 20-point checklist that goes through all the steps that you need to go through for every environment you’re trying to set up for Snowflake single sign on. 

So that at the end of that configuration you’re very confident that your single sign on is configured correctly. And once it’s configured correctly this is actually a screenshot from an off zero identity provider integration we’ve done for a couple, for one client particularly, but we’ve done it several times that shows the integration with off zero single sign on for Snowflake. 

And so once you get to this configuration, you’ll log into your Snowflake account and you’ll be prompted to single sign on. And once you click on that, it’ll take you to an interface from your identity provider such as Author here.

And then you can then sign on either through an email address or it’ll pass you straight on through if you’ve already signed on in another location. Or it will prompt you to sign on in this case with like Google or your Office 365 account and so forth and so on.

So just to talk about some use cases that we kind of see out in the world for working or integrating single sign on with Snowflake SSO in general really, we talked about federating the identity across all the organizations applications and that’s a super big deal.

I can remember before when I was working in an organization and we did not have single sign on. Every single application you want to access, you had to sign in every single time. It’s. So kind of one of those first world problems types of conversations.

But it does degrade on your work flow if you think of it that way, having to sign in to application you want to work in. The other thing that’s really great about single sign on and implementing it is that you can centrally control your users and their groups, right, who they belong to.

One of our clients was implementing single sign on and Snowflake, and they just had a set group of users that were already in the organization. This was actually for the marketing department and so they were able to really just kind of set up and allow access through single sign on just for the marketing team.

And eventually they were going to turn on and allow other groups to access Snowflake. But we were doing an advertising campaign data warehouse project. And so by turning on different groups at a time, they were able to control kind of the release of how they were leveraging Snowflake, which is pretty interesting.

Another one you might think of is just universal removal of access. So maybe you have users in your organization or employees where there’s some attrition and you can imagine they have access to all these systems.

As an employee, you know, most companies have ten or more applications that they use. So if you have one employee, more employees that are traditionally in the company, you can just go into the single identity provider and just remove their access.

And that will remove their access from all the systems such as Snowflake or Salesforce. You don’t have to go into each individual system and then say, hey, remove John or remove Jane or move Keisha from the system.

Right. It also offers better compliance for security, which might be obvious, and another one which has become very, very popular. You might have some platforms and your company might be turning it on.

Is this kind of secondary? Authentication using your phone or multi factor authentication. So I think if any of you have been using Snowflake for a while, you know that there is the multi factor authentication for standard users.

We have a best practice where in a monitoring tool here where we look for Snowflake users that have the account admin permission and our tool flags users that do not have MFA turned on, so they have the account admin role.

And a very similar thing here applies. So when you’re controlling the identity and the SSO, for Snowflake, for example, through an identity provider, you can set this multi factor authentication for those users, whether they have to sign in by their cell phone or they get an email prompt, so that you’re near certain right, or almost absolutely certain that it is that user that should be accessing your system.

And you can control all that through an identity provider. And of course with Snowflake, by enabling that capability, then it just works across all your applications. So talking about steps to install and really the configuration of Snowflake, particularly from scratch, right?

So one of the first steps is having an identity provider. You’re really not going to get far without one of those platforms I mentioned earlier to be able to configure a single sign on capability. One of the other things that’s really I mentioned, just going back and forth with configuring your identity provider with Snowflake or instance or rather your account of Snowflake, for the most part it really is at an account by account level.

So some organizations have turned on the organization capability of Snowflake. We work with several groups who still haven’t turned that on. Some companies have just one Snowflake account and some companies we’ve worked with have a dozen Snowflake accounts.

So your mileage may vary. But really configuring that usually at a production level is where we do that. So if you have multiple environments like a dev a stage in a production, you’ll probably turn on and configure it for your production environment. 

Also then aligning Snowflake roles to IDP groups. So just giving a little bit tidbit of information, since we’ve implemented this many times, one of the main questions we get is can we control all the roles in all the groups and align them inside of Snowflake and identity provider? 

So there’s better integration with some identity providers for Snowflake SSO than others. So pretty much at the time of this writing, if you will, off zero, for example, doesn’t have the same grain of sample control for a Snowflake that OT does. 

And I can do a deep dive into that at some other point. But what that really comes down to is can you control your Snowflake roles at the identity level for all the identity providers? And the real answer to that is your mileage may vary. 

So if you’re in the process as an organization looking for an identity provider specifically for Snowflake, that’s one of the considerations that we were kind of raised out there to anyone who’s looking to do that. 

And the last point here is from without going into the technical steps, like I mentioned, is to really think about other things people don’t think about when they start talking about SSO configuration. 

We worked with one group and their infrastructure team was very well familiar with implementing an identity provider. And when it came to Snowflake, they didn’t really think about some other considerations that the team had already worked on and developed within Snowflake, such as they had created service accounts. 

And so if they made one configuration incorrectly in and Snowflake to configure their identity provider, maybe like some other. Tool that they have worked on in the past. How does that affect the service accounts that might have been created for things like working with DBT, if you guys are familiar with DBT as a tool, and what about admin accounts? 

You know, what other types of controls would you, would you put in place if you knew out the severity of the account admin role within Snowflake? So all these kind of nuance things come into place when you’re implementing Snowflake with SSO as opposed to just taking it as a blank process that maybe you’ve worked on another product. 

You have to kind of look at the nuances of the particular application. And then the last one is API access as well. There is ability to turn on single sign on for Snowflake and maybe the account you’re accessing your API with, you don’t want that access to have to sign on and authenticate each time.

So that won’t work out so well. So just some nuances there and then just to kind of get to the other side of the presentation here, do we really need SSO for Snowflake? And it’s a really valid question, right?

So no, you don’t. You can use Snowflake without having to turn on single sign on, without having to do this configuration, without needing an identity provider. And that’s the one of the amazing things.

One thing we love about Snowflake is because you can just jump in there and start using it, right? Even as an enterprise tool, you don’t need to go through this process immediately to get the benefit out of it.

Now, we do recommend, of course, that if you are an enterprise organization and you’re focused on security and locking things down appropriately and aligning platforms across the organization, there are some good reasons that you want to implement single sign on aside from the ones that we just mentioned.

Right? So if you have lots of users in your organization who are going to be accessing your Snowflake instance, then it just kind of makes sense to enable some sort of. Single signon capability, at least at certain levels.

We’ve worked with groups where there’s kind of a mix because once you turn on single sign on you can actually still log in with the authenticate or the authentication process of Snowflake. So it still enables you to do that and enables you to leverage your single sign on.

You could have a mix and that could be departmentally based, it could be SecurityBased, it could be external vendor or partner based. So your Moz may vary there but there are lots of reasons you want to do that.

Also, if you’re already using the single sign on, you already have a platform or an identity provider tool that you’re using. And you can think of it like if you’re using a tablet or some other product like Looker, and somebody wants to log into Snowflake and do some testing and they want to log into Looker well, if they’re both single sign on enabled then they’re not going to be blocked by having that little hitch in their step during the workday of having to log into one and log in to the other.

Also, if you’ve already done a POC or a POV and you’re really trying to go let’s call it ga, right, general availability of Snowflake within your organization, let’s call it going into production. If you’re ready to do that, then I think one of the checkpoints that you can put out there, or milestone, if you think about it, from an agile or project based flow is to say, let’s put a sprint in there. 

Or maybe two sprints to configure single sign on for Snowflake because you’re already going through this process of implementing Snowflake. Go ahead and put it out there and maybe again you take one of the other advisory points that I mentioned earlier into consideration of whether you need it or not, but at least it’s a checkpoint for you. 

And I think I alluded to this one navigating smoothly between other platforms and I talked about this one previously about locking out users very, very quickly. Hopefully no one is abusing your Snowflake instance in your organization but. 

An IDP allows you to end single sign on, allows you to just quickly turn off users as needed across the platform. So I’ll turn it over now to Mike. Yeah. So as we near the end of the calendar year and the holiday season is upon us here, we also they’ll have some called gifts to give out here.

When you think of signing an SW by the end of December 31 of 2022, essentially matching that gift with an equal amount of free services to use within the 2023 calendar year. If you’re looking for something a little bit less costly, we do have some other free things that are available. 

Free Snowflake health check. We have a process that we come in and look at your environment and give you suggestions. This is something you don’t have to give us access to. We can do this while you drive and we shadow and tell you where to go. 

And then naturally, from a whiteboarding perspective, we have a number of organizations out there that are either just getting started with Snowflake, but they have questions about transformation and replication and A, B and C was down the list. 

And so we’re happy to have those types of conversations where we give you a direction and help with your decision making process. That’s no obligation with either one of those, other than we would love to complete those by the end of this calendar year. 

So feel free to reach out to us and we can give you more details and have further discussion. Just so from a QA perspective here, one question came in relative to, all right, Snowflake has SSO. We have some other non Snowflake applications. 

We’re in the enterprise. Do you recommend enabling SSO on all of our applications, just Snowflake? Because that is where the data. Ends up. Do you have any guidelines or rules of thumb as we look at the ecosystem outside of just Snowflake? 

Yeah, great question. So I think if you’re enabling SSO and Snowflake, it means you have an identity provider that you’re using, whether you just purchased it because you’re trying to bring yourself, your organization into the modern era, or there’s been a push to really focus on security. 

And so as you’re embarking on SSO or starting a Snowflake or a small set of applications, it does make sense to apply it to all applications that you have. You could think of it as a big step in the direction of universal security for your organization. 

But if you also think about it, it does take time. So stepping through and having a plan for implementing SSO and kind of staging and testing and piloting this in the organization is usually the best move. 

And then, of course, the Holy Grail would be to get it onto all applications that support it, because not all applications actually support SSO, but to get it into as many of the applications as you have would be a good idea.

All right, and then one final question. You mentioned that it does take time, obviously, to implement SSO. If you had to just put a rough estimate out there, you get the right people that know all the different parts of what needs to be configured. 

How long would you estimate that you can give a range of how long you think that would take to configure SSO and Snowflake? Yeah, absolutely. I think and you and this is coming from experience of implementing it many times someone will tell you that you can implement SSO in one to two days, which is not an incorrect statement. 

But to really do it correctly and go through the process of testing configuring, looking at different groups and access, particularly within Snowflake multiple accounts. So you need to set it up for each account. 

So let’s just say you have a dev and a prod sort of environment environment you’re looking at between two weeks to maybe a month to do that for a couple of environments. Again, your mileage may vary.

If it’s an extreme focus and you’ve got the users that you want engaged very tightly to this particular Sprint or milestone, then you could probably get it done in a couple of weeks. But the biggest thing is testing and understanding not just the reason you’re setting up the SSO, but the nuances.

I mentioned controlling the Snowflake roles through the IDP, which has a couple of challenges in and of itself to do. And then looking at the other aspects of just implementing Snowflake correctly, right?

Having limited user access to the account admin role. If you’re using Snowflake for API access or service account access mentioned, DBT, these are other things that obviously add time to the process. 

Thank you everyone for joining us today to learn about single sign on for Snowflake. We have a couple of events coming up over the next few months, so please be sure to RSVP for those. We’re going to take a little bit deeper dive into security in Snowflake, particularly for views, and then we’re going to talk about Apache Iceberg in Snowflake. Apache Iceberg is a big topic that’s come out of the Snowflake Summit and we’re happy to discuss and dive into that with you, with some of our experts. 

Thanks everyone for joining!