Meet the Experts: Dave Fend
Dave Fend is a SaaS veteran, working in the identity and the access management space for over 17 years. With Okta, he has helped to implement millions of identities around the world, and dozens of complex enterprise customers.
With the recent news of the CA Siteminder acquisition, we thought it was a great time to sit down with him and get his insights on deploying identity solutions in the enterprise. We were especially interested in a recent deployment he conducted with a Fortune 500 company in the healthcare industry, who chose to switch from CA Siteminder to Okta earlier this year. Dave helped them make the transition.
The problem
How to transition a large enterprise from a legacy, on-premises web access management (WAM) infrastructure to a modern, cloud-based alternative.
The strategy Dave and the Professional Services team used to achieve success
- Happy end-users
- Using a patterned approach
- Co-existing infrastructures as you go live
- A question for customers: Do you have a proper test environment for each of your apps?
So Dave, when this company came to you, using CA SiteMinder, what problem were they trying to solve with Okta?
Like many other organizations using WAM solutions, they had a few different challenges. One was a massive number of help desk calls around employee password recovery that were time consuming and expensive to resolve. They were looking, in part, for Okta to implement self-service password recovery.
They also had a lot of legacy infrastructure and implementations associated with SiteMinder, plus all the costs that go into maintaining this kind of on-premises software.
Out of curiosity, do you see that often when working in Okta Professional Services? Customers moving from on-premises systems to the Cloud?
Yes, they were like most customers we work with, trying to modernize their technology. So it's cloud if there’s an option to go to the cloud. And obviously, this was about an option to get off on-premises SiteMinder, specifically, to a cloud solution, such as Okta.
They also wanted to reduce their ongoing maintenance costs and complexity, which, for them, meant the option to not customize, and to use as much of Okta’s standard product as possible. When looking at a legacy product like SiteMinder, pretty much everything they had done there was a customized solution. So they needed to find ways to unwind all that deep customization and replace it with something that was standardized.
They experienced a lot of pain with the cost, and this is where the cloud-first strategy is a big win. It’s really hard and expensive to do upgrades to on-prem software. So the more they had customized SiteMinder, the more they found it impossible to upgrade, which just became a huge, costly, risk-prone endeavor with each lifecycle upgrade. This puts them versions behind, which puts them features behind, with an inability to keep up and respond to changes in the industry and changes in protocols, things like that.
I see similar challenges with customers who leverage other WAM solutions such as IBM Tivoli Access Manager, RSA Access Manager, and Oracle Access Manager, to name a few.
So why did they bring Okta Professional Services in to guide them in this implementation? What were they looking for from you throughout the project?
Our Professional Services has helped thousands of customers deploy Okta successfully. That experience has let them bring a proven methodology that I think the customer really bought into and could follow. Specifically, the concept of looking at their current implementation from a “pattern space” view. Deciphering their current architecture by looking for common patterns, and then solving by patterns was something they felt strong and comfortable with in our approach.
Can I ask what you mean by patterns? There was so much built historically—did you have to decipher why something was done? How did you guys land on that kind of approach?
We looked at patterns as a way to reduce the amount of time spent on the project, and the cost on the project as a whole. When you think of their application landscape, let's say it's 130-plus apps that we knew had to migrate from SiteMinder to Okta. We didn't want to look at integrating each app one at a time from design, configure, test, and rollout. Instead, we broke their apps into approximately 7 integrations patterns.
For each integration pattern, we designed how it would integrate in a co-exist model with Okta, and then how it would integrate without SiteMinder.
So instead of designing and testing for 130 apps, you are designing and testing for 7, right? And proving it out at that level. Later, for the "no SiteMinder" integration we were able to further reduce the number of patterns to 4 or 5.
So, the major benefit of using patterns is to accelerate the migration from CA to Okta?
Yes, but there's more. Identifying patterns pays off in the long term. For example, it makes it easier to add more functionality, such as MFA and Provisioning, at scale.
Oh that's great. What other reasons did they look to your team?
I think they felt very comfortable with the Okta Professional Services team. Having been involved in some other projects with them before, I think we had earned their trust and respect. We worked very closely with them, not just post sales, but also pre-sales, where we presented our integration approach. We earned their confidence and made them feel comfortable that we would walk with them, hand in hand, and ensure they were successful.
How long did it take from you starting the process to do this quick win piece?
Five to six months. For this Fortune 500 company, that is really quick! For projects that are less complex, Okta Professional Services generally deploys in weeks, not months.
Sure, sure. So when you add this authentication layer for Okta, besides the password resets being easier for the end user, did they notice anything different on their day-one? Does it look the same? Did we customize the look and feel so it felt the same for the end-user employee?
That's a good question: what was the impact of the end users and what was the thinking paradigm on this? When they came in that morning to first begin using these apps, they saw a new sign-in page. Now that was our customer’s choice, that was their page, we could have mimicked their existing one, but they chose to modernize it. They wanted it to look cleaner, to take advantage of some of the things we could do to make their sign in page look better. So we enhanced it. That was specific to what they had wanted, so the end-users did experience a difference on the sign-in page.
They also had to go through an initial one-time password recovery enrollment. They may have had to enroll in SMS or voice, whatever factor that they chose to enroll in, so we could provide that password recovery process.
Great! A happy customer… So after that success, after the deployment process, you just bring apps into Okta? Is that correct or were there other pieces before that?
Yes, that’s pretty much it. The user experience of getting to the apps remains unchanged, which had been the key directive. They saw a new sign in screen, and they may have had to enroll one time, but anything else was seamless to the end users—there were no link changes, they weren't given any special direction of anything they had to do themselves. A good way to put it is it just worked.
The flip side would be app changes, which was also a key directive from the customer. We made zero app changes. So they had 130-plus apps that were integrated with SiteMinder, with users logging into it directly. Overnight we flipped them over to authenticate to Okta, but we didn't require any change to the apps for users to continue using it. That was key.
Then we get into the next step, which is this co-existing model—to get rid of SiteMinder. To do that, yes, your apps may have to make some changes, because they have a SAML integration that is tied directly to SiteMinder. That SAML integration will have to be changed to go directly to Okta instead, and in most cases, that's very straightforward.
In other cases, if they are using more complicated capabilities in SiteMinder, where they are reliant on its web agents or proxies, then we may have to introduce something additional. In this case, we introduced a presale architecture plan, and they selected to go with F5 to be the proxy between Okta and their apps. Okta could continue to do SAML- based integrations, except SAML to F5, then F5 continues to proxy the app, removing SiteMinder and freeing the application from making any changes.
Perfect. And I would assume that, in some of these larger, older companies, some of those legacy apps would be very difficult to change out.
It can be difficult, costly, and it's risky, without the right expertise. Using Okta PS + F5 shields the customer from all that, avoiding any required application changes.
Okay, great. A co-exist model, proxy, and SAML-based. As you continued with F5 to move everything over, is there any best practices you think might be helpful to other customers looking to make this transition?
Yes, circling back to our pattern discussion. The first step of patterns is how these apps integrate to Okta through a co-exist module. The second set of patterns is how would these apps integrate without SiteMinder.
We went through all of the apps to create an app inventory and then created an app discovery questionnaire, so that we’d be able to work with individual app teams to get the necessary information from them to understand exactly which pattern they fell into, and any specific necessary changes.
Then we broke the final migration off SiteMinder into phases, looking at it as a per-pattern phase, starting with the low-hanging-fruit patterns. So, for example, apps that were cloud based and supported SAML, those were going to go first because those were simple and low risk; didn’t require changes. Once you prove success through that, you start getting into the next set of patterns, and the next, and the next. It starts to save your time for the legacy apps that are potentially going to be more difficult to move.
We approached this with a POC (proof of concept) view of the world. We did a POC to prove-out a pattern to make sure everyone felt comfortable, taking existing apps that we had, and prove out the pattern and integration work for each of the other apps. And this is actually where we hit some of the bigger challenges. Not technical, but business related, typically. So it's the sign for customers to think about: do you have a proper test environment for each of your apps?
Many times, when we were looking at apps that A. they don't have any test environment, or B. if they do have a test environment, it is not configured to use a standard enterprise sign-in technique. The company’s developers made it easier for themselves to sign in and test, but harder to prove out.
There were further issues around IDs to test with. Sometimes you hit sensitive apps where they won't give you an ID, even with which to test. Or just getting a new ID created might be difficult for them to do, as you need an ID that actually has access to the app.
Then the last one is simply scheduling. An app may have its own change program going on, with their own cycle of deadlines. So they need this environment to themselves, and they can't have down time even in a test environment. Surprising as that may sound, we sometimes had issues with just being able to take applications offline to test a change to an integration pattern. So it's something you have to be able to account for and plan.
Great. So anything else you want to highlight around deployment?
From a success standpoint, I think one highlight for me was that we successfully switched over their 130-plus apps overnight, on a Saturday (which is not easy in that window), as a joint team.
They set up a war room so that, as people came into work on Monday morning, they could call into a hot line. I believe the numbers showed that they had no noticeable increase in calls, which is phenomenal for such a massive change.
Dave is one member of an exceptional team that faces these challenges and makes these kinds of wins every day. Interested in meeting another expert? Check out our Meet Your Okta Identity Experts Web Page.
And for a deeper dive on the “challenges”, see our Untangling Five Intricate Identity Challenges eBook.
