Carolyn Woodard: Welcome to the Community IT Innovators webinar. Today we're going to be talking about single sign-on or SSO. My name is Carolyn Woodard.
I'm the Outreach Director for Community IT. I'm the moderator today.
Steve Longenecker: My name is Steve Longenecker. I'm the Director of IT Consulting at Community IT.
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.
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.
