Product · Connect your customers
SAML 2.0 SSO
Connect each customer’s SAML identity provider
A connection links an account to that customer’s IdP. You create it from a metadata URL or from three manual values. Pasted metadata XML works through the API only. Not yet tested against Entra ID, Okta, ADFS or Google.
- Customer’s IdPholds three values: ACS URL, SP entity ID, metadata URL
- signed assertion
- Customer’s realmidentity provider configuration, one per connection
- identity claims, in a signed token
- Your application(s)simply check each token
Create a connection
Three ways in. Each names where you reach it.
| Method | What you give RealmSSO | Where |
|---|---|---|
| Metadata URL | The metadata URL of the customer’s IdP. RealmSSO reads it and creates the connection’s identity provider configuration. | API, dashboard and Admin Portal |
| Pasted metadata XML | The IdP’s metadata XML, in an API request. The signing certificate in it is required. | API only. The dashboard and the Admin Portal have no screen for it. |
| Three manual values | The IdP’s entity ID, SSO URL and signing certificate. All three are required. | API and Admin Portal. The dashboard form has no manual fields. |
ACS URL
Registered by your customer in their IdP.
SP entity ID
Registered by your customer in their IdP.
SAML metadata URL
RealmSSO’s descriptor, registered by your customer in their IdP.
Your customer registers three values in their IdP. RealmSSO generates all three unless you override them. The API and the dashboard show all three. The Admin Portal shows the ACS URL and the SP entity ID after the first save.
What RealmSSO does after you create it, and where it stops
Each row says what RealmSSO does on its own, where you reach it, and its limit.
Its own identity provider configuration
Each connection gets its own identity provider configuration in the account’s realm. A realm is the separate sign-in space RealmSSO makes for each account. The configuration starts disabled. RealmSSO switches it on only after every setup step succeeds.
Signed assertions
Each SAML assertion must be signed, and its signature is verified against the IdP’s signing certificate. RealmSSO refuses metadata that holds no signing certificate.
Encrypted-response handling is not implemented yet.
Signed requests when the IdP asks
RealmSSO signs its requests to the customer’s IdP when the IdP’s metadata asks for it.
A connection entered by hand sends unsigned requests.
Certificate expiry flags
RealmSSO stores the IdP’s certificate encrypted at rest. A connection check flags a certificate that has expired or expires within 30 days. You see the flag in the API and the dashboard.
The date comes from the certificate RealmSSO read when it last set up the connection. A certificate rotated behind a metadata URL does not update it. No alert is sent.
Connection check
A check confirms the identity provider configuration exists and is enabled. For a metadata URL, it also reads the metadata again. You run it from the API or the dashboard.
It does not contact an IdP entered by hand or from XML, and it never performs a login. Connection health runs on demand. There is no scheduled check.
Test sign-in URL
A stable URL starts a sign-in for one connection. The API returns the URL.
It ends on a page of the sign-in service, not in your application.
A new IdP entity ID resets users’ links
A save that keeps the IdP’s entity ID updates the connection’s identity provider configuration in place and keeps every user’s link, including a certificate change.
A save that changes the entity ID replaces the configuration and drops every user’s link to it. A returning user then sees “Account already exists” and cannot link again by themselves.
Standard SAML 2.0 providers
RealmSSO is built to the SAML 2.0 standard.
Not yet tested against Entra ID, Okta, ADFS or Google.
Talk to the people who build it.
We run RealmSSO for you. Tell us which identity providers your customers use and how many customers you have, and we will tell you what fits today.