Introduction to SSO for Google Workspace and Microsoft 365
Hi everyone, I’m Michael Roberts, Vice President of Sales and Marketing at SPK and Associates. Now today we’re going to tackle a topic that frustrates a lot of companies and a lot of IT groups, which is single sign on or you may hear SSO. Specifically, we’re talking about how to simplify the authentication and access management in Google Workspace and Microsoft 365 without all the headaches that you might expect. And we’ll maybe dabble in a couple of other IDPs and how they may be a little bit different, but high level we’re going to really focus on Google Workspace and Microsoft 365. To help us break down this topic, I’m joined by our head of cloud and infrastructure, Mike Solinap. Mike, before we dive in, why don’t you introduce yourself?
Hello everyone, I’m Mike Solinap. I lead our cloud and infrastructure practice, and you know, aside from servers and networks and things like that, we also do a lot of SSO-related work. So, glad to be talking about this topic today.
Misconceptions of SSO in Google Workspace and Microsoft 365
Awesome. So Mike, a lot of companies are avoiding fully enabling SSO in Google Workspace or Microsoft 365 because they assume it’s really complex, which sometimes it is. As somebody who’s messed with it, I can attest it is a little daunting sometimes. But what are some of the biggest misconceptions or maybe technical hurdles that you see during a setup?
Time and Effort
Yeah, you know, the biggest misconception is that hey, it’s not worth the time and the effort, right? Because typically, what they’re doing is they’ve got access to their application, and they say, “Oh, I know how to create a local user. I’ll just create a local user, assign that user a password, and then I’m off and running.” Right? So, why do I need to go through all the trouble of setting up single sign-on? Just not worth my time, right?
And I think that requires some deeper thought. In terms of it not being worth their time, the biggest thing I’ve seen are compliance issues and compliance risks. It’s a big topic nowadays. For some of our customers that are required to adhere to compliance regulations, those regulations typically have very strict offboarding processes. When an employee leaves a company it can be really difficult to keep track of who has access to what application. You need to be able to quickly switch off access, make sure that all your bases are covered so that it doesn’t become a risk later down the line.
Likewise, another compliance risk related to the use of local accounts is that they can be ripe for sharing which is again something that compliance programs typically want to prevent—finding accounts that are shared between users who have access to one account across several groups or users. That’s a big no-no.
Another reason SSO is worth implementing is that it can really help enforce two-factor policies. As you onboard users, you can enforce these policies and it makes it a lot easier as opposed to dealing with each of these individual applications which may be handling their authentication in their own way.
Cost Savings
Another big misconception that I’ve seen is that the time savings just don’t add up. That’s not what we’ve seen across our customers. Even if users only log in once or twice per day, that amounts to a lot of time savings over the course of a month or year. For larger corporations with hundreds or thousands of users, those savings multiply.
Another topic around complexity—this is a little bit more in the weeds—but when a lot of administrators say that SSO setup is very complex, the reason is because a lot of applications oftentimes have different names for the same technical term. In Okta you’ll see the parameters described one way, and then in an application the provider might name them something completely different. It’s really hard and challenging to get those to align, and if those don’t align perfectly, authentication just doesn’t work.
Attribute Mapping
Finally, another tough technical component of setting up single sign on is attribute mapping. The identity provider has attributes like first name, last name, phone number, etc. And then your application may have a subset of those fields. The two systems need to coordinate those fields and sometimes pass information back and forth to know who the user is that’s logging in. That’s probably one of the most challenging components of setting up SSO. Usually what that results in is administrators combing through logs or just using trial and error to get through the issue.
Common SSO Challenges and How to Resolve Them
Yeah. And that obviously can take some time. And we’ve seen that with our own clients where we’re implementing SSO for them. So Mike, can you maybe walk us through some common SSO challenges that we’ve helped solve for clients, and then maybe how you and your team have helped simplify or automate that process over time?
Yes. So SPK partners with primarily Atlassian and PTC. We’ve engaged in quite a number of SSO projects throughout the years with these products in conjunction with Azure, AWS, and Okta as Michael mentioned. So we’re able to be quite efficient and also work through the best channels and resources when we need that support and things don’t quite go as planned.
Jira and Confluence Integration SSO
A common setup challenge we run into is with getting Jira and Confluence integrated with SSO. Guard is a prerequisite product that you need on the Atlassian side. You have to have it licensed and then there are some organizational steps you’ve got to do within Atlassian, such as claiming domains and setting up authentication policies. There are a lot of steps to get lined up before you can start logging in.
Another extension of SSO that we typically help out with is user provisioning. Getting users logged in is a big chunk of the value of SSO, but you also gain the additional capability of automation. For example, if I provision a new user access to Jira, maybe the next step is providing permissions via groups or access to certain projects via groups. That all can be done automatically via SCIM provisioning. We’ve helped a lot of customers with automation workflows and processes to save time and effort.
How SPK Helps Implement SSO for Clients
So interesting that there’s a scalable, repeatable process that we’ve followed. And luckily I think we connect to all the different players regardless of application that people are using. So yeah, that definitely streamlines the time it takes to implement SSO.
Now for companies that want better security and easier access management—which is the benefit of SSO to begin with—but they may lack the internal resources to set that up, how do we and our team help them in getting the most out of whatever IDP they’re using, whether it’s Google or Microsoft, and get those SSO capabilities?
Assessment
Sure. For customers that don’t necessarily have the internal resources to take on an SSO project, SPK helps out from soup to nuts and everywhere in between. Our approach always starts with thorough planning and assessments. We look at things like: what applications are you looking to connect, do they have any compatibility issues, do they have any licensing requirements? Licensing can exist either with a specific application or on the IDP side, and both have cost implications.
Roles and Permissions
Next, we work with roles and permissions. For example, in Jira or Confluence you may want certain groups of users to only have access to certain applications. We map that all out. We also look at prerequisites like networking access, connectivity, and SSL certificates.
Implementation
Once we complete the assessment, we move on to implementation. We combine our expertise with engineering applications and our cloud expertise in AWS and Azure. Aside from Google Workspace, we’ve also worked with Okta and more recently JumpCloud. We’ve also worked with on-prem identity providers like ADFS, although that’s becoming less common now as everybody shifts to the cloud.
Managed Services
Finally, ongoing managed services. That’s really our bread and butter. Once we’re done with implementation, we don’t just say goodbye. These systems require ongoing monitoring, alerting, and recurring maintenance. We don’t want something as simple as an expired SSL certificate to cause a huge outage—which some listening may relate to, since it’s very common. Our managed services help catch those before they become a problem.
Additionally, customers want to get the most out of what they’ve invested into their IDP, which means looking at new opportunities. For example, what other applications can we onboard into the system? Having a managed services relationship with SPK helps customers know it’s all taken care of for them.
Implementing SSO for Google Workspace and Microsoft 365
I love it. Thanks Mike. I appreciate your answers to some of those questions that we’ve been getting asked for quite some time. What Mike has basically said here today is that you don’t have to be intimidated or worried about how long it’s going to take to implement single sign on. With the right expertise, we can provide a lot of value. We help organizations streamline authentication and reduce the security risk Mike mentioned by onboarding and offboarding people easily, and improving user experiences across tools like Google Workspace, Microsoft, and even other IDP platforms.
So if you’re struggling with SSO implementation or you want to simplify your setup, reach out to our team—our contact page or phone number would be happy to help. If you enjoyed this video, be sure to like and subscribe to the SPK and Associates YouTube channel. Hopefully we’ll see you next time.
Thanks, Mike.
Thanks, everyone.
