Random thoughts and blurbs from the founder for Shugo – Rick Hymanson. Who's Boda? It's a word my 7 year old made up when he was 2.

Post navigation

Is Single Sign On Easy?

In the last fifteen years, I’ve designed and developed a number of software applications. Some are web applications serving hundreds of thousands of users while others are just a single web page or two serving potentially five visitors a day. FileGuardian today has over 100,000 user accounts – pretty tremendous growth from our first few months when we were lucky to have 20. To say I’ve seen it all may be an over-statement, but I’ve seen my fair share – and have lived to tell.

One of the big buzz/trends I continually hear, especially from those in the payroll and services industry, is the need for single sign on capabilities.

Why?

Typically today people need to interact with multiple systems, each serving a unique purpose to get access to all the information and data we need. For example: I have the following:

Yahoo mail account

Facebook account

Twitter account

Online banking and mortgage account

Etc…

You can see the list goes on and on and I’m sure you have your own set. With each, we have our have my own set of credentials to access our account information. Lucky for me, I use a great app called 1Password to manage all my user credentials and to create complex passwords – making access pretty simple.

In the payroll industry, the same exists. Employers may have multiple portals to sign in to for payroll, time and attendance, report retrieval, HR, etc… Employees have an ESS portal, a time and attendance portal, a pay stub portal, etc… At Shugo, we’re guilty of causing some of this because of our payroll report and pay stub delivery.

The Grand Idea

So wouldn’t it be great to have just a global single sign on service for everything we need? Yep

Is it really possible? Maybe

Is it likely? No

Isn’t it just as easy as popping open another browser window or tab? Heck no – plus when is opening a new browser window/tab an elegant solution.

I’ve completed single sign-on projects in the past for some consulting clients. I thought sharing one in particular may help shed light on why a single sign-on solution is not cut and dry or something you can just whip together overnight. There are some many considerations making it one of the more complex applications/integrations to build.

My Direct Experience

For a payroll client a few years ago, there was a need to complete single sign-on with two separate external systems. My client’s application had had over 150,000 users registered – some users would have access to both external systems, some would have access to one and some wouldn’t have access to either. That in itself presents a challenge since we’d need to identify which user has access to which external system. I didn’t think sharing how we tackled that would be a benefit. Rather, I thought sharing the integration with the external systems would be valuable.

It’s simple – I’m sure both external systems are the same

Oh only if that was true. The harsh reality is that each system had their own custom single sign-on mechanism. What you’ll find is that almost all systems have a custom single sign-on implementation.

Sure there are some industry groups trying to put standards together but we’re not there yet and some people don’t even care about them. They were probably in such a rush that creating their own was just simpler (or they didn’t know any better).

So back to my scenario — each external system had their set of standards, filled with complex integration paths with varying levels of securities and workflows. One was a simple reach out to them, get a response and if all was well, direct the user to their site. The other was way more complex involving 5 rounds of interaction before the user would be in their system.

So you can see, there was no good way to try and implement both in the same fashion – so we had to take one at a time. Each required their own set of code – including detailed and verbose logging so if someone did run into an issue, we could see where things “broke”. This meant double the time – ugh (but remember I was consulting – so maybe not ugh…)

Ok so just write the code and you’re done?

Writing the code to integrate is one thing, testing it is a whole other ballgame – and I’d argue probably even more important. Typically every web application has varying levels of security – some users are admins, some are managers, some are employees, etc… So when completing the single sign-on, we’d need to make sure the external system has the correct “role” defined for the user we were passing along.

This means that we need to test a number of scenarios. For example:

Mary is an admin in external system A – test that single sign-on to ensure that she is seamlessly signed in with admin privileges…

But Mary is just an employee in external B

Joe is a manager in external system B

Each permutation represents a different test plan. And we can just test what we deem the “happy” path scenarios; we also need to test for the “sad” path scenarios (yes plural). These are the scenarios we don’t want to see, the exception processes. And the “sad” path is much harder to test taking more time and expertise. They show the value of a good QA tester since anyone can easily test the happy path. It takes skill to test the rest.

Testing Involves Collaboration

Not only is testing complex because of the high number of scenarios, but testing involves both teams collaborating. So our team and the external system’s team need to “jump in” and do it together. Sometimes coordinating schedules can be a nightmare – pushing what we think will be a two week test plan out to three to four weeks. And remember you never test in your production environment. Each system will have a “sandbox” environment for integration testing. Sometimes this sandbox is readily available, other times it’s not which means you need to have the deployment and network teams involved, thus more delay and coordination. In my client’s case, I had to get the network team involved and that was no easy task.

Good news is that once you get going, a good testing process will flesh out issues – at least I hope it does. If it doesn’t it means that:

You have the very best developers and analysts in the world who never make a mistake

Your test plan wasn’t sufficient.

Guess which one is typically the case? You guessed it; the latter which means you’ll get “bit” when the integration is deployed into production which is VERY costly. Costly since client confidence erodes. Costly because your developers now have to spring into action identifying the issue, write new code to fix it, push the fix through another testing process and then release it out to production (keep in mind when they’re doing this, it’s pulling them off of projects they currently were working on). And most of all, it’s costly because a data breach may have resulted.

Think about it – I could have accidentally seen someone else’s information. Maybe I saw their SSN, bank account information, account number, etc… That’s not good – and it’s a data breach in every definition of the word. If it happened to me, how many other users could it have happened to as well? You then must act since each state has guidelines you must follow – it’s called your state’s data breach notification legislation. Take a minute and find what your individual state requires. I’ll just warn you it’s an expensive process.

Without boring you with more detail, I hope you see that from what a business owner may believe is a three day project turns out to be a 8 week affair with a high level of risk. Lucky for me and my client, we had a solid test plan and great teams to work with on the other side. Issues were identified during testing which we fixed immediately and all was well for our production launch.

Oh but we haven’t talked in detail about security yet.

I purposely haven’t brought up a detailed security discussion yet because this is where my #1 concern lies when conducting any single sign-on integration. It deserves its own section – it actually deserves its own whitepaper which will be VERY boring and won’t provide much value to you. So let me share a few key points.

When I think single sign-on, I think:

How does the external system I’m integrating with know it’s our system conducting the single sign-on?

Could it be that someone is just “spoofing” our system?

Could it just be a random hacker attack knowing that these systems interact?

Is all the communication between our systems secured with encryption?

Etc…

See, there are so many questions and encryption is a MUST. But that in itself presents another list of questions:

What type of encryption is it?

Is it transport or pay load encryption?

What algorithm and bit length?

Is it symmetric or asymmetric?

Does the external system restrict by IP or API key?

If IP, what if we have our system farmed (located at different places across the country) do they support requests from multiple IP addresses?

If API key, does it expire after “x” days?

If so, what’s the process to get a new key?

And of course, each external system will have its own answer to these questions. Without boring you to tears, you can see there’s a number of security challenges with any single sign on process and must be taken into account from day one. And since each system typically has their own custom implementation, that means more and more work on our end.

In Summary

Single sign-on is one of the more complex software applications to implement. Trust me, I’ve been through it. Besides building a full blown reporting system, it’s the project I dread working on the most.

It’s not a 3 day project – more like 2-3 month project per implementation (so in my example above it was a 4-6 month timespan since we had two external systems). Testing is key and requires collaboration from both parties.

Security is one of the major concerns – and where a great deal of time will be spent both in development and testing.

If you can avoid in by using an application that hosts a number of features together – it’s your best bet and will reduce your risk.