SAML SSO & SCIM

What your identity provider needs

Every SAML provider asks for the same two values. Both are ours, and both are fixed, so you can fill them in before you touch anything in RealUptime.

Our full SP metadata is published at https://realuptime.io/saml/metadata if your provider prefers to import a document rather than take typed values.

We require the assertion to be signed, which every provider does by default. We do not require the response envelope to be signed as well, because a signed assertion already fixes who the assertion is about. You do not need to enable extra signing options, and turning them on will not break anything either.

Setting it up

Four steps, in this order. The order matters: steps 2 and 3 each refuse everyone until the one before them is done, and from the outside that is indistinguishable from a broken provider.

1. Create the application in your identity provider using the two values above. Your provider will then show you its own metadata: either a downloadable XML document, or three values (an entity ID, a sign-on URL, and a signing certificate).
2. Create the connection in RealUptime. Go to Account settings → Team → Single sign-on and paste your provider's metadata XML. We read the entity ID, sign-on URL and certificate out of it. If your provider publishes no metadata document, the three fields can be entered directly instead.
3. Verify your domain. The settings page shows a DNS TXT record beginning realuptime-sso-verification=. Add it to the domain your provider will assert addresses on, then click verify. Until a domain is verified, sign-in refuses everyone: we will not let a directory assert an address on a domain it has not proved it controls.
4. Test the connection with the button on the settings page, then sign in for real at https://realuptime.io/sso.

Test connection

The test button checks everything that can be wrong before anyone tries to sign in, which in practice is most of what goes wrong with SAML: an expired or unreadable certificate, a sign-on URL served over plain http, a metadata document we cannot build a request from, and the very common case of a connection saved with no verified domain.

It reports a list rather than a verdict: each check says what it looked at and what it found. Nothing in it touches the network, so it is safe to run as often as you like.

It cannot tell you a sign-in will succeed. That needs your provider to actually answer, which is what step 4 is for.

Sign-in must start at RealUptime

Send people to https://realuptime.io/sso. They enter their work address, we send them to your provider, and your provider sends them back signed in. Bookmark that page, or link it from your intranet.

Starting from your provider instead will not work, and this is deliberate. If your identity provider offers a RealUptime tile or shortcut in its application launcher, clicking it is refused with a message pointing back here.

The reason is worth stating plainly, because it is a security decision rather than a missing feature. A sign-in that begins at the provider arrives at us as an unsolicited assertion with no request of ours attached to it, so there is nothing for the ordinary cross-site request defences to check against. It is also the exact shape used to silently sign a victim into an attacker's account. We refuse it rather than accept it and hope. Supporting it safely needs a per-connection opt-in and a confirmation step, which we have not built.

Enforcement

Enforcement is a separate switch, off by default. With it on, any member whose address is on a verified domain must sign in through your provider: passwords and linked Google, GitHub or Apple accounts are refused for them.

The account owner is always exempt. You keep your password and any linked providers whether enforcement is on or off. That is deliberate, and it is the reason turning enforcement on cannot lock your organization out of its own account: if your provider breaks, expires a certificate, or has an outage, the owner can still get in and turn enforcement off. It is also an honest reduction in what enforcement buys you, which is why it is said here and on the settings page rather than left to be discovered.

Turn it on only after a real sign-in has worked at least twice, from two different browsers. Saving new provider details never changes this switch on its own.

SCIM provisioning

SCIM 2.0 lets your directory create and deactivate RealUptime members without anyone sending an invitation. It rides on the same connection: set up SAML first.

The token is shown once, at creation, and stored hashed. Rotating it revokes the previous one in the same instant, so there is no window where both work. Every SCIM action is recorded in your account's audit log.

Provisioning requires a verified domain. Creating (or reactivating) a member whose address is on a domain this connection has not proved by DNS is refused. A SCIM create makes a working login on the directory's word alone, which is right exactly when the company controls the mailbox and wrong otherwise. Deactivating someone is always allowed, verified domain or not: removing access is your account's own business.

Deactivating a member removes their access to the account and leaves their personal login alone. The account owner is never deprovisioned by SCIM.

Not implemented yet, so that you can plan around it rather than discover it: SCIM Groups and role mapping, single logout, more than one connection per account, encrypted assertions. Roles are set in RealUptime, not from your directory.

When something is wrong

Start with your account's audit log. It distinguishes “the assertion never arrived” from “it arrived and we refused it”, which are different problems.

Still stuck? Email support@realuptime.io with your account name and roughly when the attempt was, and we will read the same audit trail you can.

Related: REST API for programmatic access, and Security for how sign-in, roles and the audit log work generally.