Hopefully this helps.
Identity Management Systems
Identity Management System are often defined by trusted sources. These are the systems we rely on for a source of record for an individual. These are not really a single piece but a combination of systems designed to manage people.
Identity Data Trusted Source
This is data of people, typically found in your HR systems. They are wide ranging, and can be as simple as AD for a small organisation.
Authorization/Authentication Trusted Source
This is a system or systems which your organization uses for AAA. In many organizations, that is just Microsoft's Active Directory, however, there are several directory based services out there and larger organizations can have systems split into different sources.
Single Sign On
Most organizations that uses SSO within the organization likely uses some sort of Federated Identity Service which allows users to have a single ID across multiple AAA systems.
Modern Federated Services allow for both SAML and OAuth 2.0 communications. If you want to be technical, OAuth isn't targeted at Authentication, it's Authorization. It does provide a mechanism for Authentication Exchange, but that's not its intent.
SAML is on built for both, and is typical for Enterprise SSO services.
If these are custom applications, one standard I have added to my development work is JWT (JSON Web Tokens) which is not really SSO per-se, but more of a mechanism to enable SSO features in modern applications, but it can handle both Authentication and Authorization.
Common IDM systems Examples
- Oracle Identity Manager (Link)
- Sailpoint IdentityIQ Link
I work with both these systems. I have many reservations about them. Sailpoint is more modern, Oracle is, well, Oracle (Lots of ups/ LOTS of downs). I always think I could build a better one (which I might attempt for fun one day).
Do it yourself setups
Understand that IDM/IAM/IdAM (Or whatever abbr you want) are designed to provide a common set of administrative functions around people and access to resources. This includes being a central repository for identity access, role management, policy deployment, and provisioning/de-provisioning of resources. Wiki for reference.
Your actual goal sounds less like IDM and more like resource management, I.E something that is not achieved by these system specifically. A few things:
- You need to identify which systems are going to allow to authenticate and/or authorize resources.
- You should have a policy around future apps about their ability to authenticate to those systems.
I think you may want to start with Federated Services and research them. This will give you an understanding of what their purpose is. Most organizations looking at SSO at scale, are looking to Federated Services to simplify thing.
This is where the term Microsoft shop comes into play, so mentioned because all their apps are MS and can authenticate to AD. I've never been to an organization that had this but, kudos if you have that simplicity.