Becoming an Identity Provider
Elsewhere the platform consumes identity — you sign in with Microsoft or a SAML provider. This is the opposite: other applications sign their users in with their ActiveManage account.
Where to find it
Architect Panel → Integration & Connections:
- OpenID Connect Provider — the console — clients, scopes, keys and the log
Architect Panel → Security:
- Authentication Methods — consuming identity, which is the other direction
- Permissions — the groups a client can be restricted to
When you want this
- You run a portal, a mobile app or a satellite system, and its users are already your users.
- A partner has built something for your members and you would rather not create a second set of accounts.
- You want one place to disable somebody, and have that take effect everywhere.
The argument for it
Every additional account store is a set of passwords to protect, a leaver process to remember and a place somebody's access outlives their relationship with you. Being the identity provider collapses those into one.
Disabling an account here signs them out of everything that trusts you — which is the property you actually wanted when you started worrying about a satellite application's account list.
What it is not
It is not a way to give an application access to your data. That is the API, and it is a separate decision with separate credentials. A connected application learns who somebody is; it does not thereby gain the ability to read your datastores.
Keeping that distinction clear saves a lot of confusion when somebody asks for "access" and means one of two quite different things.
What it costs you
You become infrastructure. If your platform is unavailable, nobody can sign in to anything that depends on it — a failure that is now wider than your own application.
That is manageable and worth knowing in advance. It argues for treating this as a production dependency: monitor it, and think about your signing keys and certificates before they expire rather than after.
The pieces
- Clients — the applications allowed to ask.
- Scopes — what a client may learn about the person.
- Grant types — how a client is allowed to obtain a token.
- Lifetimes and keys — how long tokens last and what signs them.
- Logs — what was issued and what was refused.
It is a standard
OpenID Connect is widely implemented, so most application frameworks already have a library. You are configuring something an integrator will recognise rather than explaining a bespoke arrangement — which makes onboarding a partner much easier than it sounds.
Worked example
A membership organisation runs its member records here and a separate events site built by an agency. Rather than the agency holding member passwords, the events site becomes a client. Members sign in with the account they already have, the agency never sees a credential, and a lapsed member loses access to both at once.
Recommendations
- Use it to collapse account stores, which is where the value is.
- Keep it distinct from API access in your own conversations.
- Treat it as production infrastructure once anything depends on it.
- Expect integrators to know the standard — you are not inventing anything.