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
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
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
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
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
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
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
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.
Was this guide helpful?
We read every response — it decides what we rewrite next.
Thanks for your feedback.