SmartLogin SPs — manage SAML service providers

This is where you register a new app (a service provider, or SP) to sign in through SmartLogin, Realsmart's SAML identity provider — and control exactly what information it receives when someone signs in.

Who can see this {#step-1}

SmartLogin SPs only appears in the sidebar (under Platform) when you're an admin with full access, and you're actively working within the Realsmart platform school — not MAT overview, and not any other school. Switch into that school to reach it.

It's additive — existing logins are never at risk {#step-2}

Google, Azure/Microsoft Entra ID, iSAMS and ClickView all sign in today without a row here, and they'll keep working exactly the same way whether or not you touch this page. A registered row only tailors what a specific, new service provider receives — it never removes or restricts an existing one.

Register a service provider {#step-3}

Select Register SP. You can fill the form by hand, or use Import from metadata — paste the SP's metadata XML, upload it, or fetch it from a URL — to pre-fill the entity ID, ACS URL, NameID format and certificate. Nothing is applied until you review the parsed values and confirm.

Fields worth knowing:

Entity ID — the SP's identifier. Must be unique, and can't contain "Microsoft" or "isams" (SmartLogin routes those to the Microsoft Entra service by name and would never see this row).
ACS URL — where SmartLogin sends the response. Must be HTTPS.
Attribute release — leave empty to send the full default set (everything the open path already sends today). Add rows to send only what this SP actually needs — a warning appears if a mapped attribute is the raw session token.

Check what an SP will actually receive {#step-4}

On the Edit page, the right-hand panel always shows the live attribute-release preview for that SP — whether it's using a tailored map or falling back to the full default set — so you never have to guess from the form alone.

Dry-run a login before it's live {#step-5}

Select Dry-run preview (from the list, or from an SP's edit page). Pick a service provider and a real user, and see the exact assertion SmartLogin would build — NameID, every attribute name and its resolved value. This is a preview only: it never contacts SmartLogin, never signs anything, and nothing is sent anywhere.

View SmartLogin's real IdP metadata {#step-6}

Select IdP metadata for the entity ID, endpoints, signing certificate and algorithms SmartLogin actually uses at runtime — flagged clearly wherever the published metadata.xml file disagrees (it does, in a couple of places, and always has).

Disabling or deleting a service provider {#step-7}

Both are confirm-gated and tell you exactly what happens: the SP doesn't stop being able to log in via the open default path — it simply loses its tailored attribute set and falls back to the full default one, the same as any SP with no row at all.