Single Sign-On Providers

The Available Sign-In Sources

As well as its own accounts, the platform can sign users in against a range of external sources. Each appears on the sign-in page once configured and enabled.

Where to find it

Architect Panel → Security:

• Authentication Methods — which sign-in routes are enabled

Architect Panel → Integration & Connections:

• Azure AD Tenants — Microsoft directory connections
• SAML Identity Providers — enterprise single sign-on

What is available

• ActiveManage — the platform's own accounts. Enabled by default.
• External ActiveManage Instance — signing in against another installation. Also enabled by default.
• Active Directory — on-premises corporate sign-in.
• Azure AD — Microsoft 365 and Entra organisations.
• SAML — enterprise single sign-on with the usual identity providers.
• Login Links — sign-in by a link rather than a credential.
• Xero.
• Social — Google, Microsoft, Apple, Facebook, Twitter, Amazon, GitHub, Instagram and LinkedIn.

Everything except the two defaults ships disabled

Nothing appears on your sign-in page until you enable it and enter its credentials. That is the right posture — an unexpected sign-in route is an unexpected way in.

It also means enabling one is a deliberate act, so the list of what is on should be short and explicable.

Choosing for a population

• Staff in a Microsoft organisation — Azure AD.
• Staff with another enterprise provider — SAML.
• Staff on an on-premises domain — Active Directory.
• Consumers — social logins reduce registration friction considerably.
• Partners at another ActiveManage installation — the external instance route.

Social logins are a trade

They remove the password problem and they hand part of your sign-in journey to a company with its own priorities. An account tied to a social provider can be lost if that account is closed or suspended, and you cannot do anything about it.

Offer them where registration friction is the constraint. Avoid depending on them exclusively for anything people must be able to reach.

Enable few

Every enabled route is a tile on the sign-in page and a path to maintain. Nine social providers on one page is a paralysing choice, and users who cannot remember which one they used create a second account.

Two or three, chosen for your actual population, works better than everything available.

The same person, two routes, two identities

Worth understanding before enabling several. Identity is recorded as a method plus an identifier, so somebody arriving by Google and by password is two identities unless you have deliberately linked them.

That is usually the commonest support question after enabling a second route — "it says I have no account" from somebody who definitely does.

Keep one route you control

If every administrator signs in through an external provider and that provider is unavailable, nobody can get in to fix anything. One local administrative account, strongly protected, is worth keeping.

Worked example

An organisation enables Azure AD for staff and Google for its public users, leaving the other seven social providers off. Two local administrator accounts with passkeys are retained. Support calls about "no account found" fall away once the sign-in page makes clear which route each population should use.

Recommendations

• Enable only what your populations use.
• Two or three social providers at most.
• Keep a local administrative route.
• Expect identity confusion when somebody has two routes.

Adding a Social Login

Social logins are configured per provider with credentials you obtain from that provider.

Where to find it

Architect Panel → Security:

• Authentication Methods — which sign-in routes are enabled

Architect Panel → Integration & Connections:

• OAuth Tokens — tokens issued through these routes

You register with the provider

Each provider requires you to register an application in their developer console and gives you an identifier and a secret. Those go into the sign-in method's configuration here.

The arrangement is between your organisation and that provider, on their terms — which is worth knowing when their terms change.

Redirect addresses must match exactly

The provider will only send users back to addresses you registered with them, matched exactly. This is the commonest configuration failure, and the usual causes are a trailing slash, http against https, or a development address left in place.

Remove development addresses before going live. A local address registered on a production application is a real hole.

Ask for the minimum

Providers show users what you are requesting. Asking for broad access to somebody's account when you need their name and e-mail address will be refused by people who read it — reasonably — and may attract additional review from the provider.

Request identity and nothing else unless you have a specific need.

Secrets expire

Most providers issue secrets with an expiry, and an expired one breaks sign-in completely for everybody using that route, on a date you knew in advance. Diary the renewal.

Matching to an existing account

The decision to make before enabling: when somebody signs in with a social provider using an address that already has an account, what should happen?

Linking automatically on a matching address is convenient and depends on trusting that the provider verified it. Creating a second account is safer and produces duplicates and confused users.

Whichever you choose, choose it deliberately — this is where a second route causes trouble.

Test the whole journey

Register through the provider as a genuinely new user, then sign in again as a returning one. Both paths, because they differ, and the second is the one that reveals identity-matching problems.

Have an alternative

Somebody will lose access to their social account. If that is their only route in, they lose your service too — through no fault of yours and with nothing you can do.

Let people add a password or a passkey, and make sure you hold an address you can reach them at.

Worked example

An organisation enables Google sign-in, requesting name and e-mail only, with exactly two redirect addresses registered and the development one removed before launch. Matching to an existing account is on, since the address is verified by the provider. Users are prompted to add a passkey after first sign-in, so nobody depends on Google alone.

Recommendations

• Exact redirect addresses, development ones removed.
• Request identity only.
• Decide the account-matching behaviour before enabling.
• Give users a second route in.

Configuring a SAML Provider

SAML connects the platform to an enterprise identity provider. This article covers configuring the connection; the next covers turning it on and what users experience.

Where to find it

Architect Panel → Integration & Connections:

• SAML Identity Providers — the connections themselves

Architect Panel → Security:

• Certificates — signing certificates
• Authentication Methods — which sign-in routes are enabled

Both sides need configuring

SAML is a two-ended arrangement. Your identity provider needs to know about the platform, and the platform needs to know about the identity provider. A connection that fails is usually one side missing something the other assumed.

Exchange metadata rather than typing

Most identity providers publish a metadata document describing their endpoints and certificate. Using it is faster and removes a class of transcription error — certificate fingerprints and endpoint URLs are long and unforgiving.

Where you must enter values by hand, copy and paste. Do not retype.

Attribute mapping is where connections fail

The identity provider sends attributes about the user; the platform needs to know which is the identifier, which is the e-mail address, and which is the name.

Providers differ enormously in what they call these, and the defaults rarely match. A connection that authenticates successfully and then fails to resolve a user is almost always an attribute mapping problem rather than a certificate one.

Choose a stable identifier

The attribute identifying the user should not change. An e-mail address is tempting and changes when somebody marries or the organisation renames its domain — at which point they become a new person to your system.

Prefer an immutable identifier where the provider offers one, even though it is less readable.

Certificates expire

SAML depends on signing certificates with expiry dates, and an expired one stops all sign-in at once for everybody on that connection.

It is a known date, so diary it well ahead — 60 days is sensible. This is the most common single-sign-on outage there is, and it is entirely preventable.

Agree the changeover

Certificate rotation needs both sides ready. Agree it with whoever runs the identity provider rather than doing it and hoping — a swap done unilaterally takes the connection down until the other side catches up.

Test with a real account

Not an administrator's. A test account with ordinary group membership exercises the attribute mapping and the group resolution in a way an administrator's does not, because administrators frequently bypass exactly the things you need to check.

Keep a record of the arrangement

Who the provider is, who administers it there, which attributes are mapped, and when the certificate expires. This information is needed rarely and urgently, and usually by somebody who was not involved in setting it up.

Worked example

An organisation connects to a client's identity provider by exchanging metadata, maps the provider's immutable identifier rather than the e-mail address, and tests with an ordinary account rather than an administrator's — which surfaced a name attribute mapped to the wrong field. The certificate expiry is diarised at 60 days with both sides named.

Recommendations

• Exchange metadata rather than typing values.
• Map an immutable identifier, not the e-mail address.
• Diary certificate expiry 60 days ahead.
• Test with an ordinary account.

Enabling SAML and Signing Users In

With the connection configured, enabling it puts SAML on the sign-in page. What follows is about the user experience and the first weeks.

Where to find it

Architect Panel → Integration & Connections:

• SAML Identity Providers — the connection
• SCIM User Provisioning — account lifecycle, which SAML does not do

Architect Panel → Security:

• Authentication Methods — which sign-in routes are enabled

What the user experiences

They choose the sign-in option, are sent to their own identity provider, authenticate there — with whatever it requires, including its own second factor — and are returned signed in.

The platform never sees their password, and their organisation's authentication policy applies without you implementing any of it.

Authentication is not provisioning

The distinction that catches people out. SAML signs people in; it does not create, update or deactivate accounts.

A leaver disabled at the identity provider can no longer sign in — which is most of what you wanted — but their account here, its groups and its record grants all remain. If you want the full lifecycle, that is SCIM provisioning, and it is a separate thing to set up.

Group mapping is a security boundary

Where directory groups drive platform access, somebody adding a colleague to a group at the identity provider grants access here — possibly without knowing that is what they are doing.

Keep the mapping small, explicit and written down, and review it when either side changes. This is the part of a SAML connection most likely to grant more than anybody intended.

Keep a local route in

If every administrator signs in through SAML and the identity provider is unavailable, nobody can get in to fix anything — turning somebody else's incident into yours.

Retain at least one local administrative account, protected by a passkey, and confirm it works by actually signing in with it rather than assuming.

Watch the first fortnight

Attribute mismatches, users with two identities, and people whose directory record is missing something all surface early. Check the error log and sign-in activity daily for the first couple of weeks rather than waiting to be told.

The two-identity problem

Somebody who previously signed in with a password and now arrives by SAML is two identities unless linked. The symptom is a user insisting they have an account while the system says otherwise, and it is the commonest report after go-live.

Decide how you will handle it before switching, not while people are queueing.

Sign-out is two things

Signing out of the platform does not necessarily sign somebody out of their identity provider, so clicking sign-in again may complete instantly and look as though sign-out failed. Set post-logout behaviour deliberately and be clear in your wording.

Worked example

An organisation enables SAML for staff, mapping two directory groups to two platform groups and nothing else. Two local administrator accounts with passkeys are retained and tested. In the first week, four users report having no account — all previously had password accounts, all resolved by linking, and the pattern was expected because it had been planned for.

Recommendations

• Add SCIM if you want leavers handled, not just sign-in.
• Keep group mapping small and reviewed.
• Retain and test a local administrator.
• Plan for the two-identity problem before switching.

Active Directory Sign-In

Signing users in against an on-premises Active Directory, using the accounts they already have.

Where to find it

Architect Panel → Security:

• Authentication Methods — which sign-in routes are enabled

Architect Panel → Security:

• Authentication Methods — the AD sign-in method
• Permissions — the groups directory membership can map to

When this is the right route

• Staff on a domain, with no cloud directory in play.
• An organisation not using Microsoft 365 or equivalent.
• Environments where sign-in should not depend on an internet service.

Azure AD is usually better where available

If your organisation has a cloud directory, that route is generally the better choice — no network path to maintain, works for people outside the office without a VPN, and brings the directory's own conditional access and second factor with it.

On-premises AD is the right answer when there is no cloud directory, or when there is a specific reason to keep authentication inside the network.

It needs a network path

The platform must be able to reach a domain controller. Where the platform is hosted outside your network, that means a VPN or an equivalent arrangement — and it means sign-in depends on that link being up.

Plan for the link being down, because it will be. A local administrative account matters more here than almost anywhere.

Use a dedicated service account

The connection needs an account to query the directory. Give it its own, with read access to what it needs and nothing more, and do not use a person's — it will break when they leave and their password change will take sign-in down for everybody.

Scope what is searchable

A directory contains far more than current staff — service accounts, disabled accounts, contacts, shared mailboxes. Restrict the connection to the parts of the tree containing people who should be signing in.

This also keeps sign-in fast, which matters on a large directory.

Group mapping applies here too

Where directory groups grant platform access, the same caution as SAML: keep the mapping small and explicit, and remember that somebody administering the directory can grant access here without realising.

Attributes still need mapping

Which attribute identifies the user, and which holds their e-mail address and name. As with SAML, prefer a stable identifier over one that changes when somebody's name or address does.

Test from where the platform runs

Not from a workstation. The connection is made by the server, so what matters is whether it can reach a domain controller and authenticate — a test from inside the office proves nothing about that.

Worked example

An organisation with no cloud directory connects to its on-premises AD over a site-to-site VPN, using a dedicated read-only service account scoped to the staff organisational unit. Two local administrator accounts are retained because the VPN occasionally drops overnight, and both are tested quarterly.

Recommendations

• Prefer the cloud directory where you have one.
• Dedicated service account, scoped narrowly.
• Keep local administrators — the network path will fail.
• Test from the server, not from a workstation.

Controlling Who Gets In

Enabling a sign-in source lets people authenticate. What they can then reach is a separate decision, and this is where it is made.

Where to find it

Architect Panel → Security:

• Permissions — what a new external identity lands in
• Disabled User Accounts — closing an account
• User Verification — proving something before granting more

Architect Panel → Configuration:

• Site Settings — Force External Users to Login

Authentication is not authorisation

The principle behind everything here. Somebody signing in with Google has proved they control a Google account. That is all — it says nothing about whether they should see anything of yours.

Enabling a social login without deciding what a new identity gets is how an open sign-in route becomes an open door.

Default groups do the work

What an externally-authenticated user lands in decides what they can reach. Keep it minimal — their own profile and public content — and require something further for anything else.

Check it by signing in through that route yourself and looking, rather than reasoning from configuration.

Verification as the upgrade

The clean pattern for external populations: let anybody authenticate, and require verification to gain a group. That keeps sign-in frictionless while making access something earned and reviewable.

Approval where the population should be closed

Where external users should be a known set rather than anybody who arrives, an approval step is the control — an account exists and reaches nothing until somebody confirms it should.

If you do that, make sure the queue is somebody's job. An approval queue nobody works is a set of people who cannot use your service and do not know why.

Force External Users to Login

A separate setting worth understanding precisely, because its name suggests something broader than it does. It redirects visitors arriving from IP addresses outside your whitelisted ranges to the sign-in page.

So it is a network-based control — "people outside our offices must sign in" — rather than a general rule about external users. Useful for an application that should be open inside the building and closed outside it, and it depends entirely on your IP ranges being correct and current.

Review external accounts periodically

They accumulate more quietly than staff accounts, because nobody owns the leaver process for them. Look for accounts unused for a long time, and for anybody whose access no longer matches why it was granted.

Closing off a route

Disabling a sign-in method stops new authentication through it. Consider what happens to people who used it — whether they have another way in, and whether they should.

Worked example

A partner portal allows Google and Microsoft sign-in. A new identity lands in a group granting nothing but its own profile. Verifying an employer e-mail domain awards the partner group. Accounts unused for eighteen months are disabled after a warning, and the whole arrangement was tested by signing in as a genuinely new external user before launch.

Recommendations

• Decide what an external identity gets before enabling the route.
• Verify to upgrade rather than approving everybody by hand.
• Staff any approval queue you create.
• Review external accounts — nobody else will.