The Problem with One Account per System
Groupware, ERP, MES, e-approval, an internal wiki, a cloud console. Every new system a company adopts comes with its own accounts. A company with 200 employees using 10 systems has 2,000 accounts to manage, and each system has its own password rules and expiry policy.
The same problems keep coming up in this setup:
When account management is spread across every system, the company can't easily answer the question "who has access to what?" Security incidents tend to start in exactly that gap.
Understanding the Building Blocks of SSO
Separating the IdP from the SP
Single sign-on comes down to handling login in one place. The IdP (Identity Provider, such as Microsoft Entra ID, Okta, or Keycloak) verifies who the user is. The SP (Service Provider, meaning each internal system) delivers the actual business functionality. The SP never stores passwords. It only validates a signed assertion from the IdP saying "this user has been authenticated."
SAML vs. OIDC: How to Choose
The rule of thumb is simple: for commercial packages, use whatever the product supports; for anything you build new, default to OIDC. Most IdPs support both protocols, so running both inside one company is not a problem.
Connecting Existing Systems to SSO
Integration Strategy by System Type
Mapping and Migrating Existing Accounts
The most labor-intensive part is linking each system's IDs (employee numbers, emails, arbitrary usernames) to a single unified identity. Use a stable key, such as the employee number or the IdP's immutable identifier, and build the mapping table first so you can clean up duplicate and orphaned accounts. For the cutover itself, the safest approach is to run legacy login and SSO side by side for each system for a while, then retire the old login in stages.
Automating the Account Lifecycle
Connecting to HR Data
SSO alone solves only half the problem. Hires, transfers, and departures should show up in accounts automatically as soon as HR records them. Once the IdP account is disabled on an employee's last day, login to every connected system is blocked along with it. For transfers, add rules that revoke permissions from the previous department so access doesn't keep piling up.
What SCIM Can and Can't Do
SCIM 2.0 (RFC 7643 and 7644) is a standard API that lets the IdP create, update, and delete users in each target system, and most major SaaS products support it. Internal and legacy systems often don't, though, and fine-grained permissions inside an application (menus, data scopes) are hard to express through the standard. For those systems, you either build a SCIM endpoint yourself or run a batch sync alongside it.
Hardening Security and Planning for Outages
MFA Scope and Exception Management
SSO puts all logins behind a single front door, so that door needs strong multi-factor authentication. Apply it with no exceptions to admin accounts and external access, and use risk-based policies to keep the burden reasonable for routine work on the internal network. Where exceptions are genuinely needed, such as shared terminals or shop-floor kiosks, document each one with an expiry date so exceptions don't quietly become permanent.
Designing Emergency Access for IdP Outages
If the IdP goes down, every login goes down with it. Plan for that in advance:
How POLYGLOTSOFT Supports Your SSO Rollout
POLYGLOTSOFT begins every engagement by assessing your current systems. We catalog each system's authentication method, its SAML/OIDC support, and its account counts and duplicates. From there we build a phased plan that moves from standards-ready systems to custom systems to legacy systems. One team covers the whole effort: IdP configuration, OIDC migration for in-house systems, authentication proxies for legacy apps, HR integration and SCIM endpoint development, and emergency access design. If your team is worn down by password tickets and orphaned accounts, send us the list of systems you use today. We'll propose an integration roadmap that fits how your company actually works.