Single Sign-On Providers

As well as its own accounts, ActiveManage can sign users in against external identity sources. Each appears as a tile on the login page once you have entered its credentials and switched it on.

What is available

• Active Directory — on-premises corporate sign-in.
• Azure AD / Microsoft Entra ID — Microsoft 365 organisations.
• SAML 2.0 — enterprise single sign-on with Okta, Auth0, ADFS, Google Workspace and others.
• Windows Integrated Authentication — domain users signed in with no prompt at all.
• Google, Microsoft, Apple, Amazon, GitHub, Facebook, Instagram, LinkedIn — consumer and public-facing sign-in.
• Xero — sign-in for accounting users.
• Login Links — a one-time link e-mailed to the user, with no password at all.
• Another ActiveManage instance — federating two installations.

Where to configure them

Architect Panel → Security → Authentication Methods. Each source is listed with its own credential fields and an on/off switch. SAML providers, Azure tenants, Google registrations and Xero connections each have their own record holding the detail of each connection.

Everything arrives switched off

Every external source is supplied disabled with no credentials. Nothing appears on your login page until you configure it deliberately.

How external users are identified

ActiveManage identifies an external user by the identifier their provider issues, not by their e-mail address, and records which connection they came through. That matters because e-mail addresses change and are not unique across organisations, whereas the provider's identifier is stable. It also means two different providers cannot collide into one account.

Worked Examples

• B2B SaaS: SAML for enterprise customers, Google and Microsoft for smaller ones.
• Internal system: Windows Integrated Authentication on the corporate network, Azure AD off it.
• Consumer marketplace: Google, Apple and Facebook, with ActiveManage accounts as the fallback.

Configure these in Architect Panel → Security → Authentication Methods.

The general steps

1. Register an application in the provider's own developer console.
2. Set the redirect address there to the one shown on the Authentication Methods screen.
3. Request the information you need — at minimum the user's identifier, usually their e-mail address.
4. Enter the client ID and secret in Authentication Methods.
5. Switch it on. Its tile appears on your login page.

Provider-specific points

• Apple needs a services ID, team ID, key ID and key file rather than a simple secret. It also lets users hide their real address behind a forwarding address, so do not assume you can mail them from anywhere else.
• Microsoft covers both personal and work accounts. For organisational sign-in with control over which tenant, configure Azure AD instead.
• GitHub may not release a verified e-mail address at all — handle its absence.
• Facebook and Instagram require app review before releasing e-mail addresses to a live application.
• LinkedIn restricts what an application may request; confirm what yours is approved for.

What a social sign-in actually tells you

It tells you the user controls that social account. It does not tell you their name is real, that they work anywhere in particular, or that they are over any age. Where you need to know one of those, pair the login with User Verification.

And who can now reach your login page

Do not enable a public social provider on an application that assumes its users are staff. Anyone with a Google account can then reach your sign-in. Decide what a brand-new external user is entitled to — usually nothing until approved — before you switch one on.

Worked Examples

• Consumer sign-up: Google and Apple cover most users; Apple is mandatory if you also ship an iOS app.
• Developer tool: GitHub sign-in, with an e-mail prompt for accounts that release none.
• Staff portal: Microsoft only, and social providers left off entirely.

SAML 2.0 signs users in against an external identity provider. It is the usual route when a customer already runs their own identity system, and is frequently a procurement requirement for enterprise deals.

Configuring a provider

Each identity provider is a row in the SAML Identity Providers record:

• Identity provider details — entity ID, sign-on address, logout address and certificate. All four come from the provider's own metadata; ask their administrator for it rather than transcribing by hand.
• Service provider details — your entity ID, and optionally a certificate and key. The key is only needed where the provider requires signed requests or encrypted assertions; leave it blank otherwise. It is stored encrypted.
• Attribute mappings — which attribute supplies each user field. Leave the e-mail mapping blank to use the identifier itself, which is the common case.
• Local tenant — which tenant these users belong to.
• Access mode — controls whether sign-in is permitted at all.

Giving the identity provider what it needs

ActiveManage publishes its own SAML metadata. Send that address to the identity provider's administrator and they can configure their end from it, which avoids a great deal of copying and pasting.

Multi-tenant installations

SAML settings are deliberately not copied into new tenants. Cloning one organisation's identity trust settings into another would be a serious mistake, so each tenant configures its own.

Common problems

1. Certificate mismatch — the certificate here must be the current one at the identity provider. Certificates expire and get rotated, usually without anyone telling you.
2. Nothing happens after sign-in — check the access mode permits it.
3. Users arrive with no name or address — the attribute mappings do not match what the provider actually sends. Ask them for a sample assertion.

Worked Examples

• Enterprise customer onboarding: one SAML provider row per customer, each pointed at their own tenant.
• Internal Entra ID: SAML or Azure AD both work; Azure AD is usually less configuration.

Configuring an identity provider is only half of a SAML deployment. The other half is how users actually reach it — and SAML deliberately does not work like the other sign-in methods, which catches people out.

There is no SAML tile on the login page

Architect Panel → Security → Authentication Methods lists a SAML row, and it is switched off. Leave it off — switching it on does nothing.

Every other external method has one set of credentials and therefore one tile. SAML does not: you may have a dozen identity providers configured, each belonging to a different customer, and a single tile would have no way of knowing which one a visitor wanted. The login page skips this row when building its tile list, in the same way it skips the inbound trust from another ActiveManage instance.

The row still has to exist. It reserves SAML's login-method number and it is what labels a SAML user's sign-in method in the record audit panel.

Enablement is per identity provider

Sign-in is permitted by the access mode on each row of the SAML Identity Providers record — exactly as it works for Azure AD tenants. A provider whose access mode does not permit logins will authenticate at the identity provider and then be refused here, so this is the first thing to check when a customer says single sign-on "does nothing".

Sending users to the right place

Each identity provider has its own sign-in address, identified by the provider's row number:

/saml/?provider=N

Because there is no tile, you decide how users reach it. In practice that is usually one of:

• A link from the customer's own intranet or portal — the most common arrangement, and the one enterprise customers expect.
• A bookmark distributed to their staff.
• A "Sign in with your organisation" button you add to your own login page, pointing at the right provider.
• A per-customer subdomain or landing page that redirects to their provider.

You can also pass a destination so the user lands where they were heading rather than on the home page.

If every SAML sign-in fails

1. Check the SAML row exists in Authentication Methods. Without it, every SAML sign-in fails and a clear explanation is written to the Error Log. This is the symptom on an installation where the platform was updated but the accompanying database patch was not applied.
2. Check the access mode on the provider permits logins.
3. Check the certificate matches the current one at the identity provider — certificates get rotated, usually without anybody telling you.
4. Check the attribute mappings against a sample assertion if users arrive with no name or e-mail address.

Worked Examples

• Enterprise SaaS: one provider row per customer, each linked from that customer's own intranet, with your standard login page left untouched.
• Single corporate identity provider: one provider row, and your login page's primary button pointed straight at it.
• Pilot: configure the provider with access mode set to refuse logins, confirm the assertion arrives correctly in the logs, then permit logins.

Where ActiveManage runs on a server configured for Windows integrated authentication, domain users can be signed in without typing anything at all — they open the site and they are in.

How it works

A dedicated address on your site is protected by the web server itself, so the browser authenticates against Active Directory before ActiveManage is involved. ActiveManage then looks that user up in the directory and signs them in as an ordinary Active Directory user — the same identity a typed sign-in produces. No password is ever handled by the application.

What the server needs

• On IIS — Windows Authentication on and Anonymous Authentication off, for that folder only. The required configuration file is supplied.
• On Apache — a Kerberos authentication block requiring a valid domain user. An example configuration is supplied alongside it.

This is a server configuration task rather than something done in the Architect Panel, so it needs whoever administers the web server.

The security depends on that configuration staying in place

If the supplied configuration is removed, or the server is later changed to allow anonymous access, ActiveManage simply falls back to the normal login form — an unauthenticated visitor is never treated as signed in. But do not remove it.

When it does not work

Any failure returns the user to the normal login page and stops it retrying in a loop, with the reason written to the Error Log.

1. Landing back at the login page usually means integrated authentication is not actually being enforced — check anonymous access is disabled.
2. Authentication succeeding but sign-in failing usually means the directory account cannot read the user, or the domain is not configured in ActiveManage.
3. Users still prompted for credentials means the site is not in the browser's trusted intranet zone — a browser or group policy setting.

Worked Examples

• Internal intranet: staff on the corporate network never see a login page.
• Hybrid working: integrated authentication in the office, Azure AD when remote.

An external identity source will authenticate anybody it recognises. That is rarely the same set of people you want inside your application, so external users pass through an approval layer.

How it works

On first sign-in an external user is recorded, and whether they may proceed depends on the access mode configured against the source they came through. Their name and address are cached locally so your application can show them without calling the provider on every page.

This works identically for every external source — Azure AD, SAML, Google and all the social providers — so there is one thing to understand rather than eight.

Blocking individual users

External users are subject to the same controls as everybody else — see Blocked User Accounts and Blocked IP Addresses.

Practical advice

• Decide what a brand-new external user gets before you switch a source on. An account with no groups and no permissions is a far safer default than one that inherits something broad.
• Review who has arrived periodically, particularly after enabling a public provider.
• Where the population must be provably restricted — students, one organisation's staff — combine the login source with a gating verification type. See User Verification.
• Removing somebody from your application does not remove them from the provider. If they still have a working Google account they can still reach your login page; block the account here.

Worked Examples

• Public sign-up: new users land in a "Pending" group with read-only access until approved.
• Client portal: new users must pass an organisation verification before seeing anything.
• Leaver process: block the account in ActiveManage as well as disabling it at the identity provider.