We're using Okta for SSO, but we've discovered that around 40 applications weren't properly integrated into our identity management system. These apps range from custom internal tools developed by our engineering team over the years to legacy on-premises systems we've inherited from acquisitions, vendor portals that don't support SAML, and contractor-developed applications that have their own authentication methods.
During a recent security incident, we realized we had no quick way to verify which systems the compromised account could access, leading to a tedious manual check that took days. We're still grappling with issues like finding orphaned accounts months after employees leave since no one is taking ownership of the lifecycle for these applications. Additionally, onboarding new hires requires manual provisioning across more than 15 different systems, and our last SOC 2 audit pointed out our lack of visibility into access across non-SSO applications.
We've attempted manual access reviews (which often go unanswered), created scripts to pull user lists (but they quickly become outdated), and explored traditional identity governance and administration platforms, which typically rely on having APIs and connectors.
For those managing hybrid environments that include custom and legacy apps, how do you effectively discover and manage the lifecycle of systems that are outside your identity provider? I'm looking for practical solutions that have been successful, not just theoretical ideas.
5 Answers
Start by figuring out what applications you actually have. If your identity provider doesn’t know they exist, it's impossible to manage them effectively. You can only start to get a handle on lifecycle management once you know what you're dealing with.
It ultimately depends on your team's size and structure, but here's what we've been doing:
1. All new apps need to go through a security approval process to assess access needs before reaching IT. Only IT can create new applications.
2. We send out a monthly report listing apps with expiring secrets and certificates to multiple teams.
3. We hold quarterly app review meetings with IT, security, and relevant managers to decide which apps to retire.
4. Every six months, we conduct ownership and access reviews; if we can’t get in touch with the app owner after three attempts, we disable it.
This tight process helps us ensure applications don’t slip through the cracks, and when they do get disabled, it certainly gets everyone’s attention!
For the discovery part, consider activating Defender for Cloud Apps if you're using M365. It can analyze your firewall and proxy logs to identify every SaaS application your users are accessing, not just those integrated with Okta. In our first week, we discovered over 40 apps that nobody in IT was even aware of, regardless of their SAML support!
We've utilized Okta's Secure Web Authentication feature, which allows you to manage credentials and delegate access similar to a password manager. This way, we can control who accesses shared accounts, such as Adobe, limiting them to specific members of the creative team. However, it has its downsides since a savvy user can usually extract shared passwords using browser tools, but it hasn’t caused significant issues with regular employee access.
The real challenge is that your IdP will only be aware of the apps that were properly onboarded, leaving everything else as a manual inventory issue. Teams usually map their systems out by checking logs, repositories, and outdated user lists until they can transition those legacy applications to be SSO-enabled.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures