Single Sign On (SSO) is the next step in protecting your nonprofit from cyber risks.
View Video
Listen to Podcast
In pt 1, Phil and Steve define SSO and go over what it does and doesn’t do. We discuss the unfortunate fact that each app interacts with SSO differently so you have to enable it for each. However, if you use Google or Microsoft you already have some basic tools to implement SSO. In part 2, we discuss implementation and roll out, and answer questions
Like podcasts? Find our full archive here or anywhere you listen to podcasts: search Community IT Innovators Nonprofit Technology Topics on Apple, Google, Stitcher, Pandora, and more. Or ask your smart speaker.
Transcript below
If you have heard about Single Sign On (SSO) and wondered what it can do for your nonprofit, this webinar explains the concept and examines the ways that SSO can help your organization be more productive and work more safely online.
Single Sign-On (SSO) is a pivotal security and usability tool for any modern organization. By enabling users to access multiple applications with one set of login credentials, SSO not only simplifies the authentication process but also enhances security.
At the most basic level, when a user is logged in via SSO, they access the websites and tools they use for work through that SSO service. Those individual websites and tools are configured to trust the SSO-providing service. Organizations can set up a stand-alone SSO service like Okta or use an existing service that provides the functionality as an option, like Microsoft 365 or Google Workspace. We discussed all of these options in the webinar.
SSO allows organizations to focus their identity management efforts. It reduces the risk of password fatigue and decreases the likelihood of phishing attacks. SSO allows for improved governance around which applications users can access. User account provisioning and deprovisioning can be more efficient than when each application is managed separately. And SSO should also help staff work more smoothly without needing to pause to log in to tools and sites throughout the day. More details are available in our blog post SSO for nonprofits.
With the evolution of AI fueling more sophisticated cyber-attacks, Community IT often recommends implementing SSO as another layer of protection. View or listen to this webinar to delve deeper into the benefits of SSO, understand implementation strategies, and learn how it can streamline your workflow, bolster security, and improve user experience.
Is your nonprofit protected?
As with all our webinars, this presentation is appropriate for an audience of varied IT experience. You do not have to have previous experience with SSO or cybersecurity to benefit from this webinar. Community IT believes strongly that your IT vendor should be able to explain everything without jargon or lingo.
Community IT is proudly vendor-agnostic, and our webinars cover a range of topics and discussions. Webinars are never a sales pitch, always a way to share our knowledge with our community.
Presenters:
As Director of IT Consulting, Steve Longenecker divides his time at Community IT primarily between managing the company’s Projects Team and consulting with clients on IT planning. Steve brings a deep background in IT support and strategic IT management experience to his work with clients. His thoughtful and empathetic demeanor helps non-technical nonprofit leaders manage their IT projects and understand the Community IT partnership approach.
Steve also specializes in Information Architecture and migrations, implementations, file-sharing platforms, collaboration tools, and Google Workspace support. His knowledge of nonprofit budgeting and management styles make him an invaluable partner in technology projects.
Steve’s appreciation for working at Community IT Innovators is rooted in respect for the company’s vision, and for his excellent colleagues. Before joining Community IT, Steve was an 8th grade science teacher at Takoma Park Middle School, and – though that was a long time ago now – he still draws on lessons learned in that first career.
Steve is MCSE and Microsoft 365 Fundamentals MS 900 certified and is a certified Professional Google Workspace Administrator. He has a B.A. in Biology from Earlham College in Richmond, IN and a Masters in the Art of Teaching from Tufts University in Massachusetts.
Originally from Indonesia, Phil Oswald Christano joined Community IT Innovators in January 2000 and he is now a Senior Engineer. In addition to providing support to his assigned clients, he also provides escalation support for the network admins and engineers, performs project QAs, and network audits. With a passion in staff and human development, he holds the unofficial title of coach and mentor.
Prior to Community IT, Phil lived in Goshen, Indiana where he went to college and gained 4 years of Information Technology (IT) experience as an IT Consultant to small businesses, and later as a Systems Administrator in a manufacturing company. Phil holds a Bachelor of Arts degree in Computer Systems with concentration in Information Systems from Goshen College. He is a VMware Certified Professional (VCP5).
Carolyn Woodard is currently head of Marketing and Outreach at Community IT Innovators. She has served many roles at Community IT, from client to project manager to marketing. With over twenty years of experience in the nonprofit world, including as a nonprofit technology project manager and Director of IT at both large and small organizations, Carolyn knows the frustrations and delights of working with technology professionals, accidental techies, executives, and staff to deliver your organization’s mission and keep your IT infrastructure operating. She has a master’s degree in Nonprofit Management from Johns Hopkins University and received her undergraduate degree in English Literature from Williams College. She was happy to moderate this webinar on Single Sign On (SSO) for your nonprofit organization.
Transcript
Carolyn Woodard: Welcome to the Community IT Innovators webinar. Today, we’re going to be talking about single sign-on or SSO. And I’m excited to have two of our experts with me today to discuss the security tool and how it can make life simpler for your nonprofit staff. And for your IT and for your cybersecurity support. If you don’t know what SSO is, you’ve come to the right webinar. We’re going to explain the concept and the advantages it can give your nonprofit.
And if you’re thinking about moving to SSO, we are going to help with some important points to consider as you make that decision and as you roll it out and implement it for your users.
My name is Carolyn Woodard. I’m the Outreach Director for Community IT. I’m the moderator today. I’m very happy to hear from our experts, Steve and Phil. But first, I’m going to cover our learning objectives.
Learning Objectives
Our learning objectives for today are that by the end of the webinar, you should be able to
- learn what single sign-on is and is not,
- understand single sign-on’s value to your organization,
- note the mechanics of single sign-on. It’s not simple sign-on. It’s a little bit complicated, and
- learn planning considerations for rolling out SSO to your staff.
And so now I’d like to turn it over to Steve to introduce himself.
Introductions
Steve Longenecker: Sure. Thanks, Carolyn. My name is Steve Longenecker. I’m the Director of IT Consulting at Community IT. I’ve been here for 20 years or will have been here for 20 years come September, so I’m looking forward to that anniversary. I’m pleased to talk to you about single sign-on today.
Phil, who’s introducing himself in a second, is the technical expert, but I’ve collaborated with Phil on quite a few implementations now. My role has been more of the consultative and project management and change management person, while Phil’s done the actual technical work. Phil?
Phil Oswald Christano: Hi, I’m Phil Oswald Christano, and I have been with Community IT for more than 24 years, and I am one of the Senior Project Engineers. Definitely one of the projects that I frequently work on is SSO implementation and configuration.
Carolyn Woodard: Great, thank you so much both of you for being here with us, and I’m really looking forward to taking advantage of your technical and change management expertise. Before we begin, if you’re not familiar with Community IT, a little bit more about us. We are 100% employee-owned managed services provider, so we provide outsourced IT support.
We work exclusively with nonprofit organizations, and our mission is to help nonprofits accomplish their missions through the effective use of technology. We are big fans of what well-managed IT can do for your nonprofit. We serve nonprofits across the United States.
We’ve been doing this for over 20 years. We are technology experts and are consistently given the MSP 501 recognition for being a top MSP, which is an honor we received again in 2024. But more than being technology experts, we’re also experts in how nonprofits work, what values are important to you, and what you need from your IT. Nonprofits are actually the only reason that we do this work.
I want to remind everyone that for these presentations, Community IT is vendor agnostic, so we only make recommendations to our clients and only based on their specific business needs. And we never try to get a client into a product because we get an incentive or a benefit from that.
But we do consider ourselves a best of breed IT provider. It’s our job to know the landscape, the tools that are available, reputable, and widely used. And we make recommendations on that basis for our clients based on their budget needs and their business priorities.
We got a lot of good questions at registration, so we’re going to try and answer as many of those as we can today. But anything that we can’t get to, I’m going to ask our experts to give us some written thoughts, and I’ll append those to the transcript.
Single Sign On (SSO)
Steve, what is Single Sign On?
Steve Longenecker: What is this thing that this whole webinar is about? Sure.
The idea of Single Sign On, the idea is that we have all of us now in this world of internet connectivity started using web applications, software as a service, and we have a bunch of them, right? Whether it’s Zoom or Slack, your HR platform, your payroll platform, Salesforce, whatever, all of these different third-party applications would traditionally each have their own username and password and identity database, and they each maintain their own. So you have one username, it might be the same username, it might be your email address you use over and over again, but each of them has their own password, and maybe you use the same password for each of them, but you know that if you change the password for one, it doesn’t affect the passwords for the other, because they’re all separate. And you shouldn’t use the same password for each of them, because if one gets compromised, then all of your systems get compromised, and we all know that already.
The idea of single sign-on is that instead of having each of those applications maintain their own database of identities, you tell them to trust your own identity provider, which is shorthand for that as IdP. And we’ll use that abbreviation, I’m sure, in the rest of this webinar.
You tell all the apps, hey, trust my IdP.
My IdP is going to authenticate all my organization’s users. We’re going to trust the IdP. And if the IdP says yes, you can have access to this third-party application, and then the application will let them in.
They don’t have to put in a separate password. They just use the password that they use to log on to the IdP.
The analogy for this, the real-world analogy for this might be, let’s say you’re a student at a university. There’s a gym, there’s a cafeteria, there’s dorms, labs, all of these things. And wouldn’t it be nuts if each of those facilities had to maintain their own list of students’ names and pictures, so they made sure that the students’ names matched the actual person who’s walking in?
It’s a lot easier if there’s an agreed upon source of identity. That might be the ID that the university’s security office issues each student and faculty member and staff person and they wear on a lanyard. And that lanyard is basically trusted by all these different facilities. So as a university student, you can get into the gym with your lanyard, get in the cafeteria with your lanyard. You might even be able to get into the library across town that’s not owned by the university, but has reciprocity with the university for access, and you can walk into that.
Interestingly enough, maybe it doesn’t get you into the chemistry lab. Chemistry lab is kind of a dangerous place. You’re not a chemistry student. You’re not on the list. Even though there’s no list, that lanyard is not a known student.
And similarly, it gets you into your dorm, but not the dorm across the common, because that’s another place where there’s sensitivity, and you want to limit access. So that’s the real-world example of what single sign-on is. Phil, you’re going to talk a little bit here about some of the more details.
Phil Oswald Christano: So just like what Steve was saying, this is kind of like a transition between using physical key on campus to open a different section of the campus to using a key card, where these days students are issued with a key card that can open all based on what you’re allowed to open and not.
SSO is not a password manager.
So SSO is not a password manager. With a password manager, you have the master login and that unlocks the database that help you log in to other places.
With single sign-on, the authority relies on the IdP itself. The individual applications don’t actually necessarily process the login. The identity provider will do that. It works hand in hand, and the IdP is the authority.
Now, the HR information system, some of them would like and would prefer, if possible, to become the IdP because it is HR. And some of them provide synchronization with other IdP, such as Okta, Entra or Google Workspace. However, the synchronization doesn’t always work both ways because of the security of HR, where it should not be open to everyone.
Steve Longenecker: We list some of the most common SSO identity providers here on this slide. Microsoft, Google, and Okta. That was a question that came up in the pre-registration. People asked whether Google Workspace could be an SSO provider, and it can.
Microsoft 365 is a very popular one because you already are in there. I don’t believe you have to pay anything extra for, or do you, Phil? Can you remind me?
Phil Oswald Christano: You don’t. SSO comes with most baselines.
Steve Longenecker: With the baseline. That’s what I remembered, yeah.
And then Okta does have some charity pricing available. It more or less made its bones as an identity provider, whereas Microsoft 365 and Google Workspace sort of… I wouldn’t say they tacked it on at all, because it’s a very robust in both of those platforms. But obviously, their most basic mission is to provide a bunch of services, identity being just one of them.
Okta is an identity provider. And so they’ve really focused on that, and that focus does have some value.
Carolyn Woodard: We have someone in the chat mentioning that Okta gives 50 free licenses to nonprofits.
Steve Longenecker: We could say a lot more about that HR information system, because it’s kind of an interesting tension between HR, where it does make sense that the system of record of who’s in your organization and who is not, and when you’re first onboarding a new person, you start in HR, so wouldn’t it make sense that everything flows from that? But traditionally, HR systems aren’t as strong on the IT side.
Now, that might change in the years ahead, but right now we would say you’re probably better off using a system that’s born and bred in the IT world for your SSO.
Carolyn Woodard: That makes sense. We have a good question before we move on.
Many websites ask if you want to use your Google Sign In to sign in to them. Is that SSO if you’re using Google?
Steve Longenecker: It is not the same. That’s considered social log-ons, and it’s different from the level of your organization’s IT department and the configurations and governance that you have with single sign-on. It’s more an agreement between, say, Slack and Google, where the companies, Slack and Google, have agreed to trust Google for an identity, but it’s at that level, and you don’t have the control points that you would with true single sign-on.
We wouldn’t say that you should be strongly encouraging the use of social. I’m not sure that it’s harmful, per se, but it’s certainly not the same thing as SSO. I’m about to talk about the value of SSO for an organization. Social doesn’t have anywhere near as many of these value points.
Phil Oswald Christano: Yeah, and also SSO is configured. Some of them allow you to disable other forms such as social, so that you can control that a little bit.
Value of Single Sign On (SSO) to Your Nonprofit Organization
Steve Longenecker: Okay, so what is the value of SSO to your organization? 50% of you are thinking about doing it, and 20% of you have already done it, so this is probably a quick slide here. But you know, it’s really great that there’s this single point of access.
This is good for users because once they’re in, they’re in, right? It’s very convenient. It helps them, users, fight password fatigue instead of having to maintain a zillion different passwords, and each one should be unique.
And a password manager helps with that, and that’s fine. And if that’s where you’re at as an organization, password managers are much better than no password managers and no single sign-on. But different than password managers, single sign-on provides additional things that are valuable to your organization’s IT department if they’re interested in governance and security.
Because it’s a single point of access, you can see everything’s logged at that point of access, right? So if, let’s say, there was a breach in any system, you’d wonder whether that breach has passed into other systems. Maybe someone did reuse the password.
Maybe there’s other stuff going on. It takes a lot of work to investigate that if you’re looking at the logs of every single app separately. If you only have to look at the logs of your IdP because everything’s there, that’s very helpful.
It also provides a control point. At that single point of access, you can say who has access to what. Back to the university example, you can say that they have access to the lab, or they don’t, or to this dorm and not that dorm.
So that is a very powerful thing. Instead of having to go into each app separately and configuring all of that separately, it’s much easier to do it in one place. And then, of course, because it’s a single point of access, that point of access, you can really focus on it in terms of security.
In the next slide, Phil’s going to talk about securing that logon to the IDP.
Configuring and Securing the Identity Provider (IdP) of your SSO
Phil Oswald Christano: So, yes, again, the IdP is really where the authority and the trust is.
First of all, I want to say that your security, when you have SSO configured, is about as good as how your IdP is configured. So, I believe there was a question, SSO and MFA (MultiFactor Authentication), and their relationship.
If your IdP is not secured very well, for example, doesn’t even have MFA configured, then in terms of security, you’re not really that much better off. Still an improvement, but you’re still vulnerable against attacks and whatnot. It is important to make sure that the IdP is configured correctly and securely.
And when the IdP is configured correctly, then it is good to have it as the trusting point for all of the applications. Generally speaking, many authentication methods are supported, but they don’t offer equal security, because as we know these days, the attackers try new things all the time, right? And some are definitely more secure than others in terms of the IdP capability.
Creating Rules on When and Where the IdP Must Be Re-Authenticated
And with the IdP authentication, there’s always a question how often it should be renewed, and how monitoring is done. Is there alerting for any suspicious behavior and risk? So it’s important, again, to make sure the control is done correctly on the IdP.
Carolyn Woodard: Do you guys have a recommendation of that how often? Because I feel like that’s something just anecdotally that a lot of people complain about, is “oh, I have to change my passport again, oh, I have to change my passport again.”
Steve Longenecker: Yeah, so this is not about how often the passport needs to be renewed. It needs to be changed. These days, people say if you do really secure authentication with a very strong MFA method, changing the password is actually less important than it used to be.
This is more about, okay, I’ve already logged in to the IdP on this computer. Now I’ve closed the lid. I’ve done my lunch. I come back. I open it up again. Do I need to log in again or will it trust me because it remembers that I was just on? Or do I need to log in? Let’s say it’s been a week. Do I need to log in again?
Now, it’s clear if I got on a different laptop, I should have to log in, right? That’s a different laptop. But if it’s the same laptop, how often do I need to renew that authentication?
So that’s a question. There is so much granularity and control. You can make rules that say you can trust the laptop unless it changes its location. Because that might be an indication that the laptop has been stolen, right? That’s why you can’t just trust the laptop forever, because you don’t know who’s actually using the laptop. So these are not trivial.
MultiFactor Authentication Methods
There’s a lot more to say about this. We probably don’t have time to go into all the different MFA methods. But the hackers have just gotten so much more sophisticated that what used to be, oh, if you have MFA, you’re good to go, is no longer true.
Now they talk about phishing-proof MFA methods, and they talk about these security keys that you actually have to physically plug into your computer or connect via Bluetooth, or it’s called NFC, I guess, to your phone, because you actually need to have physical proximity to the MFA “key.” Anyway, we can’t go into all of that now, but these are not trivial things.
It is important to understand, though, that maybe an application, I’m just going to pick an application at random, like Slack, say, you may not have nearly as many granular controls over Slack logins. You, I’m sure, have some controls, but if the Slack just trusts your IdP, and your IdP is a good IdP, you have all that control at the IdP level.
That’s that point of having the secure SSO, being able to focus this control in one place, rather than across a hundred different applications.
Carolyn Woodard: Thank you so much for that clarification. I think that really helps.
Phil Oswald Christano: Also, Carolyn, to answer your question, it depends on who your IdP is and what features are available to you. For example, with Microsoft, you can upgrade your security level by getting additional license, and then that will allow you to get more granular control and alerts and classification, things like that.
Carolyn Woodard: This makes me wonder, and I know we’re going to talk a little bit later about implementation, but something to think about since we have several people who are getting started with it, I’m wondering if there are ways to implement SSO at a general level, and then as you get more comfortable using the IdP and the single sign-on to maybe increase that granularity. We could talk about that later.
Logging in to an SSO
What does this look like when someone logs in?
Steve Longenecker: Right. Two different ways, generally speaking, that you can log in to an application using single sign-on.
Service Provider Initiated Logon
The first way is SP-initiated or service provider-initiated. You just go to the same service provider/app, and you might put in your email address as your username, like you would normally. It sees that email address and says, oh, this is an SSO, this email address is configured by an organization to trust this IdP. So then it just sends packets of information to the IdP.
Let’s say you’re using Microsoft 365 Azure or Entra ID, I guess it’s called now, as your IdP. So you’re logging in to Slack, but instead of seeing a Slack login, up pops what looks like a Microsoft 365 login window. And in fact, that’s what it is.
And you put in your Microsoft 365 password, and then up pops the Microsoft 365 MFA challenge. Did you have to put the number matching into your phone? Because that’s what’s happening. You are actually logging in to Microsoft. If you’re already logged into Microsoft 365, it may be seamless. Microsoft already knows that you’ve logged in, and it just says to Slack, yep, I know who that person is. Let them in.
IdP Initiated Logon
The other way is called, is the IdP initiated. And this is pretty cool.
And I think Okta does it best. It’s one of the examples, probably, where the fact that this is Okta’s focus and their reason for existing, they probably do it best. But where you can get these app dashboards. We have Google on the bottom left, and then we’ve got Okta in the middle, and then we’ve got Microsoft 365’s app dashboard on the upper right.
But each of these is like you’ve logged in to the IdP, and then you’ve browsed to your app dashboard, if you will, with this list of icons. Click on an icon, and you go straight into the application, which is pretty cool. It’s a nice way for an IT department to make available all of the different resources.
And of course, different tiles would be available to different people. If you’re in the finance department, you have a tile for the finance system. If you’re in the communications department, you don’t.
One thing to add with the service provider initiated, depending on the application, there’s different behavior. For example, with some, as soon as you put in your email address, right away it takes you to the IdP login. While some others, you have to click login with Okta or login with Entra, or login with Google as the IdP.
Carolyn Woodard: So it really varies from one to another depending on the application.
Steve Longenecker: Yeah, we’re seeing questions and chats about, are all apps the same? We’re getting to the fact that they are not, and we’re about to start talking about that.
How do the Applications Talk to the SSO?
Phil Oswald Christano: Another part of the SSO mechanics is the protocols itself. Basically, in plain language, that’s how the application talks to the IdP, right? So most IdPs can use all of the protocols that we have in the slide, SAML, OAuth and OIDC and all this.
But not all applications can use all of those. Some can use one, while others use the other. So that makes it a little bit tricky sometimes to configure, because it’s not all the same way.
Depending on what protocols it’s using and its capability, you have to configure it differently.
Planning the SSO Implementation
Carolyn Woodard: Well, I know often when we’re first working with a client, we are gathering all the information about all the apps that they’re using and different teams are using, and it can be challenging to put that list together. And that’s a list that you have to have for SSO, it sounds like.
Steve Longenecker: Well, if you’re going to be comprehensive, yes.
Our poll at the beginning alluded to the fact that it’s not all or nothing. You can implement SSO for the five most commonly used apps or even for 80% of the apps that you use. We’ll talk about the fact that some apps don’t even support SSO, or that you might have circumstances that constrain your ability to implement SSO for apps even if they support it.
So yes, a list of all the apps that you want to do SSO with is part of the early on the implementation planning for sure.
And then if you’re doing it, great. Start reading the knowledge base articles that hopefully those applications are providing. If you’re doing it with an IT partner, hopefully they have experience with those apps.
I can speak from … I will speak for Phil’s experience. (laughs) You know, early on especially, we were doing SSO with apps that we hadn’t done before. And we’ll still, every implementation we’ll still, I’m sure, surface apps that we’ve not done before.
And each one’s kind of a rodeo. I mean, sometimes it’s really straightforward, but other times like, “oh, this is unexpected.” And you know, you have to work your way through the challenges because every app is a little bit different.
Phil Oswald Christano: Yeah, in fact, there are times where you have to open a ticket with the app provider before you can even configure because they have to enable it on their end before we can even proceed. So that makes it a little bit interesting.
Automatic User Account Provisioning for SSO
Another part of SSO, one capability is user account provisioning.
And what this is, is traditionally when you use an application, let’s just pick on Slack, you have to create the account in Slack in order for your user to be able to log in as part of your organization. Some applications will allow automatic user account provisioning. And what that means is you create the account in your IdP, say Google or Microsoft or Okta, and then there’s a rule that will enable you to automatically create an account in the application itself, such as Slack, for all your users.
And then that way, it cuts down on your setup time because you just need to make sure that you have enough licenses for all this, and then the provisioning can happen on its own. And some can even assign licenses. So for example, you can have a workflow where you create the user in Okta, you add the user in the group where Microsoft 365 is one of the applications, and it can create the user automatically, and depending on which group you put it in, it will provision the right license as well as the role of the person.
Now, a side note, not all applications support this, because again, to do this account provisioning, there is a certain protocol that needs to be used, and not all applications are using that protocol. Some you still have to create the account manually.
Steve Longenecker: The SSO will still work, but you have to go into the application to create the account. This is great for efficiency, especially if you’ve got a lot of users that are coming and going, because it’s not just provisioning, but deprovisioning that can happen automatically. So when someone’s off-boarded, you just go into Okta, say, or Entra ID on Microsoft 365, go to that user, that person who’s leaving the organization, and you just make some configuration changes there, and it just turns off not just their account there, but in these other applications, and retrieves the license for you and all of that stuff sort of automagically, which is great.
Every App Is Different
Carolyn Woodard: We’re going to get into this section now, which is about implementation. Steve, I think you were going to talk a little bit more about apps.
Steve Longenecker: Yeah, so, all right, we’ve already blown the big story, which is that every app is different. When you’re doing an SSO implementation, you get your list of apps, you go through them. Some apps require special licensing for SSO.
We’ll pick on Slack again. Our audience, of course, cares about the fact that Slack has a TechSoup available license, which is really a great pricing for nonprofits. But wouldn’t you know it, if you want to use SSO with that Slack, you need to upgrade that license. I continue to find it crazy that SSO isn’t a baseline part of any application.
At the same time, I’m sympathetic to particularly small applications that are just doing their best to deliver the functionality that makes their application competitive in a marketplace that’s tough, and they have to keep getting rid of bugs and delivering new features and everything else. And to suddenly have to also add single sign-on functionality on top of that, it’s almost always on all these applications’ roadmaps, but I can see why that might not be the first thing that they’re doing in terms of where they’re investing their development dollars.
So not all apps even support SSO. Someone referenced this in one of the open questions. Aziz said that they put off a big implementation of SSO because the apps that they wanted to do SSO with weren’t supporting the automatic user provisioning and deprovisioning. For them, that was a big reason for even doing SSO in the first place.
And I get that. Looking into all of these apps are things that you need to do ahead of the implementation. It’s going to be hard to know everything from the planning stage, but you can at least get a handle on – does the application even support it, what protocol does it use, look and see whether there’s a nice knowledge base article that’s understandable about how to implement the SSO.
This knowledge base article would normally be published on the application side, right? If you’re implementing it for Salesforce, you should be able to go to Salesforce’s knowledge base and do a search for SSO, and you should be able to find, hopefully, articles that tell you how to do SSO. Really big apps with a lot of development dollars and support dollars might have specific instructions for Okta versus Entra ID versus Google. Other applications are just going to have very general instructions about SSO in general, and they’re going to count on you as the implementer to be able to translate that to the specific IDP that you’re using.
And some won’t have any knowledge base article at all. And then you’re like, okay, this is not a good sign. And it’s not, but it doesn’t mean that it can’t be done, but it’s a steeper hill, for sure.
Carolyn Woodard: I feel maybe for the people on this webinar who are IT managers, unfortunately, there is no switch that you can turn on. You do have to look into every app. You need that list of your apps. You need to know if they support it, if they need a special license, what the ins and outs are for each one, unfortunately.
If you are a non-tech person and you are thinking about this, that would be a great question for your MSP or outsourced provider or your tech department at your organization to ask them about.
Evaluating SSO Benefits Vs Risks Without SSO
Steve Longenecker: Right. And there’s different things that you want to evaluate, right? An application that’s used by everybody in the organization has bigger bang for your buck in terms of SSO than one that’s just used by two people. If it’s just used by two people, maybe it’s not worth doing at all.
Or it also depends on like the risk associated with it in terms of like, well, what happens if it is breached? You know, like, “oh, shoot, someone got into our New York Times subscription and they’re reading the New York Times for free.” Low risk, like not a big impact to your organization. You might prefer not to have that account compromised, but it’s not the end of the world. They rearranged, you know, what your favorite section was. Now sports is at the top of the list. It shouldn’t be, you know, but that’s it. Whereas if someone can break into your HR system, it’s game over for finance, so maybe those really need to be in SSO, where you’ve got that logging and that control point and all the things that we talked about before.
There are different things that you’re considering as you’re mapping out which app, because you might not get all your applications. You probably won’t get all your applications. And, and which ones you do get and prioritize are going to be varying according to those considerations.
Phil Oswald Christano: And that’s a good reminder that the context of SSO implementation is really security, right? So even when there is a challenge such as, you know, what Aziz is talking about, where you have to upgrade license, it’s important to, to bring it up the chain to help people understand in the organization that the context of security. So, yes, it might be an additional investment that we need to put in, but if it reduces the security risk, it’s worth it.
It might need to wait until the next fiscal year, maybe, so that it can be put in the in the budget. But I would not just drop it completely simply because you have to upgrade the license.
Carolyn Woodard: And Steve, can you go over this slide a little bit?
Steve Longenecker: Yes, yes, and it actually fits. It does fit in with a couple of points that people have made. And these are these are two other additional considerations in terms of your application evaluations.
Shared Accounts Don’t Work with SSO
So, shared user accounts. I just mentioned the New York Times subscription. Perhaps six people in the organization are in the communications department or the programs department all need to read the New York Times to look for references to their area that they’re programmatically following or whatever. And you don’t want to buy six accounts. So you buy one account and then share the username and password among your six staffers. The New York Times would frown upon that.
But it also doesn’t work with SSO, right? Because you can’t have those six people. There’s no one-to-many or many-to-one setup for the most part with SSO.
So that’s just not going to work. We would probably tell you to buy more subscriptions, since that’s probably the right thing to do. Anyway, no more to say about that.
Members, Volunteers, Contractors – Without an Organization User Account
The other one that’s a troublesome spot. Let’s say that you have a finance system and there’s a consultant who does some accounting work for you, who doesn’t have a login with your IdP, right? Because they don’t need one.
And as long as they’re like logging into the finance system with their username and password that you’ve given them in the finance system, that’s good enough. With single sign-on, it depends on the application. Some applications allow you to use single sign-on, and the regular username and password.
And some say, nope, once you’ve turned on single sign-on, you have to use single sign-on. In which case, you either can’t do it for that person, or you need to give that consultant a user account in your IdP. It’s just the way. There are just certain constraints that you get into with this, and it’s hard to do.
Phil Oswald Christano: And with that, this is also where it matters which IdP you’re using, because as a nonprofit organization, Microsoft 365, you’re free to keep on creating accounts, because what matters is what license you apply. In Okta, just to create an account, you need the license.
Another challenge with SSO implementation is, again, each application behaves very differently. For example, with Slack, when SSO is configured and enabled, then all the users basically have to do the binding between an existing account with the IdP. And this is something that cannot be done by the administrator. So basically, when it is enabled, Slack will send out an email, automatic email to all the users, giving them instruction on how to bind it.
With LastPass, for example, if you use that and you configure it for SSO, the user will have to re-encrypt their fault. So again, it requires the user to actually do some work to make it work.
Steve Longenecker: Just a little click or two. It’s not that big a deal, but it can be confusing. It just adds to your change management burden.
Phil Oswald Christano: But as we all know, though, with anything change management, sometimes people just completely ignore those e-mails, and then suddenly, hey, it’s not working, right? And also, some will require federation, like with the Adobe.
Change Management When Implementing SSO
Change management in the SSO implementation is really important. It needs a lot of communication because, first of all, people will have to do things slightly differently than the usual, and usually that alone just causes issues.
And like what you said earlier, planning is very important, getting the buy-in from management, or giving education to the users, it’s very important to communicate why we’re doing what we’re doing.
And as far as strategy, because each app has different impact, different change management, it’s always good to start with the lower stakes. Applications that are being used maybe once a month; those are good ones to change first. Application that you rarely use, or only a small group of people are using, those are a good low-hanging fruit.
However, applications like Zoom, for example, where people are using it all the time, you really have to time it and plan it correctly to make sure it goes smoothly and there’s no interruption.
And of course, we need to ask people to be flexible during this transition because it’s not unusual that we do a configuration, we turn it on after testing it, and something’s still not quite right, then we have to roll it back and nothing is perfect.
And also, in regard to planning, it’s important to know that even though, like what Steve was saying, the application may have documentation, and the IdP may have documentation, in my experience, they’re not always updated. Sometimes the documentation is outdated, or a smaller company is bought by a larger company, now the name changed, and all the formatting suddenly changed. It can be a nightmare in that way. The planning is really important in order to successfully implement SSO.
Why Do SSO Then?
Steve Longenecker: All true, but I think we made it too scary. We’ve done this a bunch of times, and once it’s done, I think the users really like it. It is super convenient to just have one thing that they have to authenticate once, and then get into everything at once.
And if you do start with that lower-stake stuff, like logging into your benefits site, which you only have to do when you want to check your IRA account or something like that. It’s not mission-critical, it’s not happening all the time. Start with that stuff, go slow, build up people’s familiarity and experience with SSO.
Then you hit the hard ones, the big ones, because people will have familiarity with the process at that point, their use of the communication, they’ve already logged into IdP a bunch, they know how to find the app dashboard, and you sort of gain some momentum doing it that way. And it’s gone really well with most of our projects, and it’s been fun. And while there’s always been an app or two that makes you grind your teeth … a lot of the apps are actually quite smooth, and it’s no big deal, and it’s over and done with, you know, Phil’s done, what, three or four app transitions at a time sometimes, right? And then, yeah, it’s not that big a deal.
Carolyn Woodard: Well, I will put that plug in. You know, we do have some expertise in this. When I was saying before, if you are not the technical person, finding somebody that you trust and can talk to about it makes sense.
Q&A
We have a great question in the Q&A. For small organizations already using a password manager, is SSO worth the effort? If some important apps aren’t going to support SSO, you’d still have to use the password manager anyway for those.
So, especially small organizations, can you guys talk a little bit about kind of the security versus convenience trade-off there? And being able to manage it, right? This is an IT item that you have to be able to have the capacity to manage.
Phil Oswald Christano: I will start with the second part of the question. What happens with applications that do not support SSO? Okta, for example, has what’s called SWA, secure web application, where Okta will act as your password manager.
And in fact, you can set it up so that individuals can configure each application themselves for that. Or it can be an application where the login is actually shared among a group of people. That is the workaround.
Microsoft has something similar. It works slightly differently. But essentially, they can become the password manager.
Google’s implementation is a little bit different because Google wants Chrome browser to be the password manager. In a way, that’s built in there.
To answer the first question, we need to remember that again, password manager is still different than SSO, right?
Because the level of security gain that you get out of SSO is much more than just simply using password manager. Yeah, I don’t know, Steve, if you have any…
Steve Longenecker: No, everything you’re saying is true, and I don’t want to enable someone to take undue risks with his organization. I will say that a password manager is a lot better than no password manager. And it is a big lift for small organizations to do SSO.
I do believe that SSO is a maturing. We’ve seen improvements just in the last few years. It’s maturing. I think putting it down the list of priorities is probably going to be okay for a small organization that has other things that they need to take care of. But Phil’s point is still completely right. They are not equivalent, and we shouldn’t think of them as equivalents.
Sometimes you just can’t do SSO. It’s like too much, too much.
Phil Oswald Christano: Right.
But also keep in mind that if you’re already using either Google for your email or Microsoft 365 as your platform, you already have the IdP, right? You have already half of what you need to set this up. I would still consider it.
SSO Review
Carolyn Woodard: I want to go back over our learning objectives, which we hope that everyone feels you have learned about single sign-on, what it is, what it entails. You can understand the value of it to your organization. I think we just got into some of the questions. We didn’t even talk about costs, right? But you have to trade off that with what are your risks? Do you have some apps that are riskier than others? Do you have the capacity to do SSO on your end?
And of course, as you said, a password manager is better than no password manager. Making sure that you have some training and people who are conscious of security in everything that they’re doing, whether or not you have single sign-on in there. We learned some of the mechanics of how it works.
Of course, we can only scratch the surface, but I hope that people feel like you could understand what we’re talking about. If you have more questions, please get in touch with us. We love to talk about this sort of thing.
And then we touched at the end on a lot of those considerations in the change management. Thank you, Phil, for sharing that with us and just making sure you’re communicating and telling people why, and practicing on the smaller apps and then doing Zoom or the apps that people are using every day that if they can’t log in, they’re going to freak out.
I want to go really quickly to just let you know that next month, I’m going to be talking with our CEO, Johann Hammerstrom, and our Director of Information Systems and Technology, Pat Sprehe, about a common fear in nonprofit technology, the fear of missing out or FOMO. We’re going to talk about ways to make strategic IT decisions at your organization, whether or not you’re the IT person, and ways of embracing change or learning to avoid shiny object syndrome with new technology, particularly AI. But I think SSO is another good example in your cybersecurity of making sure you have a plan and that you’re working with that plan when new bright things come in and maybe you want to do them, so you have a way to evaluate what you’re putting in place. That’s going to be at 3 p.m. Eastern, noon Pacific on August 21st.
I just want to thank you, Phil and Steve, for helping us out with understanding what SSO is and then some of these considerations. And I love getting into some of the technical considerations as well. So, Phil, thank you so much for joining us.
And thanks, everyone, who spent an hour with us today. Really appreciate it. And we’ll let you go on your way. Thank you so much.
Additional Questions from SSO Webinar:
What is the difference and benefit of SSO vs MFA?
Single Sign On (SSO) is very different from Multi Factor Authentication. Your nonprofit should usually be using both.
Your staff should be using MFA on every logon and on personal logons also. We have seen AI-enabled phishing attempts on staff members’ personal Facebook accounts where the hackers understand that Facebook account belongs to the CFO at a nonprofit that they want to target. MFA methods and tools are changing to counter new hacking threats and remain one of the strongest tools we have to thwart cyberthreats.
Single Sign On as reviewed in this webinar is an enterprise system for an IT department to provide a different level of authentication to work apps and platforms, using a trusted IdP.
Because your staff members’ single logon to the IdP will provide access to multiple apps, it is very important that MFA is used to authenticate that logon.
Further, not all MFA methods are equally effective at preventing account compromise. Community IT has increased the rigor of its MFA method preference in response to a recent spate of Adversary-in-the-Middle (AitM) attacks. We now prefer MFA methods that are classified as Phishing-resistant MFA. This essentially means that the MFA method must be physically connected to the device that is logging in (either with a security key on the device itself, as in Windows Hello) or via USB or a local radio wave protocol like Bluetooth or NFC (near field communication) using something like a YubiKey.
Single Sign On and MFA work hand in hand but are not the same thing.
Many websites ask if you want to use your Google sign-in to sign in to them. Is that using SSO? (even though Google doesn’t call it that)
No. Single Sign On is a cybersecurity tool that your IT department will enable, that allows a granular level of security and reporting, for multiple apps and platforms. It is controlled by your organization. Other login options that we often see, such as “Sign in with Google” or “Sign in with Apple” or “Sign in with Facebook”, are called Social Login or “Social Sign-in”.
Social Login is designed to provide users with convenient registration and account creation and login experience. When a user logs in using a Social Login, the social platform receives the login request and provides the authentication. The major downside of Social Login is that there is no way for administrators to enforce the user’s security credentials at the social platform, so it only marginally decreases security risks.
It’s also worth noting that the incentive for this structure is to increase the ability for Meta, Google and Apple to collect user data for advertising purposes.
What types of applications do organizations include in an SSO plan? Are there certain applications or systems that shouldn’t be included?
Ideally an SSO will cover every application, and that is our recommendation. In reality, that is sometimes impractical or in some cases impossible. Some apps do not have an integration with your SSO or may require additional licenses that are more costly, and that cost may require more review.
Where possible, we would recommend that the more completely your SSO includes every app, the more secure your organization will be and the better your IT department will be able to respond to security incidents. Even in cases where only a few staff members are accessing an app, including that app in SSO will provide all the benefits of SSO that we discussed in the webinar.
Does SSO only apply to employees? What about members?
As covered in the webinar, for SSO to work the member or volunteer will have to have a logon/account in the organization’s IdP to be able to be covered under the SSO. SSO will also not work well for a single account shared by multiple staff. Each of these scenarios is something that your organization will need to be intentional about as you make decisions on implementing SSO.
How does SSO impact applications that send passcodes texts to an individual cell phone? I’m not clear what it would take to give our members SSO into several platforms we use. In particular, how does SSO impact applications that send passcode pin texts to an individual cell phone upon log in
When SSO is set up the applications will no longer send a second factor authentication, such as an authentication passcode text to individual cell phones since the application is not authenticating the users at all. With SSO, the applications trust the IdP to authenticate the users.
When you login to the application’s site, the IdP receives the login request. If you are not already authenticated by the IdP on that Internet browser, you would be prompted to logon to the IdP, not to the application. In other words, at that point, you might be prompted to logon to Okta or Microsoft 365 or Google Workspace, or whatever IdP has been integrated with the application by your organization. You will probably have an MFA challenge that may utilize an individual’s cell phone at the logon to the IdP. Once that is done, the application lets you in.
For small organizations already using a password manager, is SSO worth the effort? Can’t we just continue to use a password manager?
A password manager and an SSO work in different ways. As discussed in the webinar, SSO can be challenging to implement across every app that staff are using. SSO provides a higher level of security for your organization, so when assessing the return on investment – and the capacity of your IT department to manage an SSO tool – those costs and effort should be weighed against your risk assessment.
A smaller organization facing specific risks due to the nature of your work may decide to invest in SSO for the additional protection and management. A smaller organization working in a less controversial field or with lower IT capacity may decide that strong cybersecurity training is a better investment for now than SSO.
Community IT recommends being intentional about decision making and documenting your decisions now so that your future IT staff understand them. Remember too that SSO fits within your overall cybersecurity plan. You may decide to build up capacity before attempting to implement SSO, and as long as you have a current cybersecurity plan in place, with protections that match your risk assessment, you can be intentional about waiting to implement SSO.
Does SSO require each system that one would access SSO, needs to work with SSO? That is, can SSO be used on any and all accounts that I need to access? If so, is SSO enough of a standard that any IdP would work with any site that can do SSO?
As discussed in the webinar, not all applications support or allow SSO. The applications must be capable of integrating with SSO solutions and support the necessary protocols, before anyone can configure the Identity Provider (IdP) for SSO.
How do accounting applications fare? Do they allow SSO? Any that don’t?
As with any other kind of application, the answer is that it varies. NetSuite has a knowledge base article on setting up SSO, as does Blackbaud’s Financial Edge. QuickBooks Online has lots of user forums asking if this can be done or requesting the feature (but no knowledge base articles on setting it up).
Cost estimates
If you are using Microsoft 365 or Google Workspace you already have about half of what you need to implement SSO via those platform tools. Okta provides 50 free licenses to nonprofits for their SSO product. In general, SSO tool licenses are reasonable for nonprofits, but that license does not itself contain all the costs you need to budget for.
As discussed in the webinar, you should have a list of all the apps you want to include, and you must research which apps will require a higher-level license that may cost more.
Do not forget to include staff time to implement and manage SSO in your cost estimates.
However, your increased costs can be weighed against greater security, depending on your risk assessment. Estimates of the “average” cost of a security incident vary widely but any incident will have financial costs and consequences for your nonprofit.
Employee management during implementation
As discussed in the webinar, communication and change management are essential for an SSO implementation, because you are changing the way staff logon to do their work; any small (or large) glitches in roll-out are going to be very impactful in staff ability to work and overall happiness with the “new system.”
As with any change management, form a team or assign a staff member to “own” the change, chart out the impacts and the stakeholders, and communicate frequently the “why” in addition to the “what/when/how” logons will change.
Enable some “easier” apps first – used infrequently, or by few staff members – so that you can practice before rolling out large frequently used apps like Zoom or Teams.
If you have champions and super-users, use them to help train and reassure other staff and be available to help with communications during rollout.
Plan to gather feedback during and after rollout; plan to address concerns and mistakes transparently. Give thanks and praise often.
Work with stakeholders to avoid rollout during mission critical times like an annual fundraiser, where logon interruptions would be more disruptive.
How does one set up SSO with the nonprofit version of MS365? Is it included in the Business Premium package?
SSO is included with the Microsoft 365 Business Premium bundle. When using “Microsoft 365” for SSO, you are technically integrating your applications with what was previously called Azure Active Directory but is now rebranded as Entra ID. For further information, please seehttps://learn.microsoft.com/en-us/entra/identity/enterprise-apps/plan-sso-deployment.
As far as “how it is done,” even though the behavior, features, nuances, and granular configuration may vary, SSO is configured in more or less in the same way regardless of the application (the Service Provider, or SP) or the Identity provider (the IdP, whether Entra ID, Google, Okta or some other platform). An administrator account in the SP and an administrator account in the IdP need to perform the documented configuration tasks on each side.
We’ve tried SSO in the past but ran into difficulties. How easy is it to get it set up if you’re already using MSFT365/Entra ID?
As in the answer to the preceding question, “it depends” on which applications you are integrating with Entra ID SSO. Some applications support SSO better than others.
How to move away from the ADFS (Active Directory Federation Services) and engage in another IDP provider?
If Active Directory is something you need, you may find that syncing your Active Directory with a traditional cloud SSO provider like Okta or Microsoft 365’s Entra ID will work for you.
In such a situation, the traditional cloud SSO provider views your on-prem Active Directory as the IdP; Active Directory would be authoritative for provisioning and deprovisioning user accounts and so forth. But Okta or Entra ID would be your IdP (your SSO provider) as far as your third-party applications would be concerned. Community IT has many clients using this approach.
If, however, you are a smaller nonprofit that is able to move all IT services to the cloud, an on-prem Active Directory may be something that you can retire. The process for doing so is beyond the scope of this Q&A, but it is definitely doable and is something Community IT encourages when possible.