SSO and SAML

Last reviewed: 2026-05-24

SAML Single Sign-On lets your team sign in to Accedo through your existing identity provider — Okta, Azure AD / Microsoft Entra, Google Workspace, OneLogin, or any other SAML 2.0 IdP. Once it's on, users are redirected to your IdP instead of typing a password into Accedo. SSO is available on the Standard and Premium plans; on Free the SSO panel shows an upgrade prompt instead of the form.

Before you start

You need an admin role in Accedo — only admins see Settings → Single Sign-On.
You need admin access to a SAML 2.0 IdP that can publish a metadata URL.
Each person who'll use SSO must already exist in Users and roles with the same email their IdP will release. SAML doesn't auto-create accounts; logins are matched to Accedo users by email.

Service provider details

Some identity providers — most commonly Google Workspace — ask for Accedo's service-provider details when you first create the SAML app, before you've had a chance to paste anything into Accedo. You can find your tenant's values at Settings → Single Sign-On → Service provider details, with a copy button next to each. The values follow these formulas, where the user pool ID and hosted-UI domain are unique to your tenant:

Entity ID — urn:amazon:cognito:sp:<your-user-pool-id>
ACS URL (also called "Assertion Consumer Service URL", "SAML reply URL", or "Single sign-on URL") — https://<your-hosted-ui-domain>/saml2/idpresponse

Both values are stable for the life of your tenant — you only need to copy them once per IdP. Okta, Microsoft Entra ID, and OneLogin generally do not need them up front (they auto-discover the service-provider side from the metadata Accedo serves). Google Workspace is the notable exception, which is why it has its own section below.

Step 1: Create the SAML app in your IdP

In your IdP's admin console, create a new SAML 2.0 application for Accedo. Accedo provisions the service-provider side automatically once you save your IdP metadata, so most IdPs need nothing from you up front beyond a name and an icon. If your IdP requires entity ID and ACS URL before it will let you save, copy them from Settings → Single Sign-On (see Service provider details).

Set the IdP to release these SAML attributes (Accedo reads the standard XML namespace URIs):

Email — http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. Required — this is what matches the assertion to an Accedo user.
Given name — http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname.
Surname — http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname.

Assign the app to the users or groups allowed to sign in through SSO.

NameID best practices

The NameID is the value your IdP sends to uniquely identify each user in the SAML assertion. It must be a stable, non-email identifier — a value that never changes for the life of the user account. Configure it before your first rollout. Common stable choices, one per major IdP:

Active Directory / ADFS — objectGUID
Okta — user.id
Microsoft Entra ID / Azure AD — objectId (user object ID)
Google Workspace — a stable directory subject_id / user ID, not the primary email

Do not use the user's email address as the NameID. If you use email as NameID and a user's email later changes — marriage, name change, domain consolidation — your IdP sends a different NameID for the same person. Accedo (via Cognito) then treats them as a different person: they lose access to their existing work history, and you get a support ticket. A stable, non-email NameID survives email changes.

Email, given name, and surname are still released as regular SAML attributes (see the URIs in Step 1) — Accedo refreshes a user's name from those attributes on every sign-in. The NameID is only the durable identity key, so keeping it stable and separate from email is what protects continuity of access.

One-time disruption caveat: changing the NameID after users have already signed in is a one-time disruption — existing users were linked under the old NameID and would need to be re-mapped (effectively re-provisioned under the new identifier). Decide on a stable NameID before your first rollout to avoid this.

Step 2: Copy your IdP metadata URL or download the XML

Most IdPs (Okta, Microsoft Entra ID / Azure AD, OneLogin) expose their SAML metadata as a single HTTPS URL — sometimes labelled "Metadata URL", "Federation Metadata", or "App Federation Metadata Url". Confirm it loads in a browser and returns XML; if it requires authentication or sits behind a VPN, Accedo won't be able to fetch it and SSO won't enable.

Google Workspace is the notable exception: it does not publish a public metadata URL. Instead, the Google Admin console offers a Download metadata button on the SAML app page that gives you an XML file. Accedo accepts the file contents directly — see Google Workspace below.

Step 3: Paste the metadata into Accedo

In Accedo, go to Settings → Single Sign-On. The panel has two tabs:

Metadata URL. Use this for IdPs that publish a public metadata URL (Okta, Entra ID, OneLogin). Paste the URL into the field and click Save. The form rejects anything that isn't a valid http:// or https:// URL.
Paste XML. Use this for IdPs that only provide a downloadable XML file (Google Workspace, some on-prem ADFS configurations). Either paste the XML directly into the text area or click Or upload XML file to load it from your machine. Click Save when you're done. The XML must have an EntityDescriptor root element with an entityID attribute — Accedo rejects anything else with an actionable error.

Saving (either mode) triggers an async workspace update — the page shows Configuration in progress — your changes may take 1–2 minutes to take effect. Wait for that window to pass before testing sign-in.

Google Workspace

Google Workspace does not expose a public metadata URL, so you have to use the Paste XML tab. The end-to-end flow is:

In the Google Admin console, go to Apps → Web and mobile apps → Add app → Add custom SAML app.
Give it a name (e.g. "Accedo") and an icon, then click Continue.
On the Google Identity Provider details screen, click Download metadata — Google offers an XML file (GoogleIDPMetadata.xml) for download. Save it locally. Click Continue.
When Google asks for service-provider details (ACS URL and Entity ID), copy them from Accedo at Settings → Single Sign-On → Service provider details. See Service provider details above for the exact values and format.
On the Attributes screen, map your Google directory's Primary email, First name, and Last name to the schemas.xmlsoap.org URIs listed in Step 1. Save the app.
Assign the app to the users or organisational units allowed to sign in through SSO.
In Accedo, go to Settings → Single Sign-On → Paste XML, click Or upload XML file, choose the GoogleIDPMetadata.xml you downloaded, and click Save. You can also open the file in a text editor and paste its contents into the text area if you prefer.

When you need to rotate the IdP certificate, Google issues a new metadata XML — just repeat the upload step. There is no scheduled refresh; Accedo applies whatever XML you last saved.

Verify before rollout

Test the round trip with a non-critical account before you tell the rest of the team to switch:

Open an incognito / private window and go to your workspace URL (e.g. acme.yesaccedo.com).
Pick the SSO option on the sign-in page. You should be redirected to your IdP, authenticate there, and land back on Accedo's Dashboard.
Confirm the signed-in profile shows the right email, first name, and last name. If any are blank, the IdP isn't releasing that attribute.

To turn SSO off, click Remove on the SSO panel — that triggers the same async update in reverse and password sign-in becomes the only option.

Requiring SSO (SSO-only)

Once you have verified the round trip works, you can require SSO for your workspace. With SSO-only enabled, every sign-in must go through your identity provider — direct username/password sign-in and password resets are blocked for all users, so no one can sidestep your IdP (and the policies it enforces, such as MFA or conditional access).

Important — plan your recovery before you enable this. If your IdP becomes unavailable (an expired SAML certificate, an Okta or Entra outage, a misconfigured app), no one in your workspace can sign in, including admins. There is no per-user password bypass by design.

The only break-glass path is to contact Accedo support and ask them to temporarily turn SSO-only off for your workspace. You can then sign in with a password, fix your IdP, and re-enable SSO-only. Because of this, only enable SSO-only after you have:

Completed the round-trip test above with a real IdP account.
Confirmed at least one admin can sign in via SSO.
Noted how to reach Accedo support so you can request a temporary toggle if your IdP goes down.

Common pitfalls

Email mismatch. If the IdP sends a different email than the Accedo user record, sign-in fails. Update one side so they match — comparison is case-insensitive but otherwise literal.
Missing email attribute. Some IdPs default to releasing only NameID. Add an explicit attribute statement mapped to the email URI above.
Multiple email claims. If your IdP releases both email and the schemas.xmlsoap.org URI, Accedo reads the schemas.xmlsoap.org one. Make sure that one carries the canonical address.
Clock skew. SAML assertions are time-bound. If your IdP host's clock drifts more than a few minutes, assertions arrive expired and sign-in fails with a generic error. Sync NTP on the IdP side.
Metadata URL is private. If Accedo can't reach the URL from the public internet, the update fails. Use a publicly reachable endpoint.