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=NBecause 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
- 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.
- Check the access mode on the provider permits logins.
- Check the certificate matches the current one at the identity provider — certificates get rotated, usually without anybody telling you.
- 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.