Single Sign On (SSO) for Nonprofits pt 1

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.

In part 1, our guests Steve Longenecker and Phil Oswald Christano 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 app. 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 from the webinar audience. 

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.

_______________________________
Start a conversation :)

• Register to attend a webinar in real time, and find all past transcripts at https://communityit.com/webinars/
• email Carolyn at cwoodard@communityit.com
• on LinkedIn

Thanks for listening.

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.