Yesterday we announced Partner Roaming. Today, three questions kept landing in our inbox.
"Does Partner Roaming work with SSO?"
Yes. If a student's home institution signs them in through Google, Microsoft, Okta, or their own SAML identity provider, roaming uses the exact same sign in when they visit a partner. They never see a password field at the partner's login page at all.
"What if the partner institution doesn't use SSO, or uses a different one?"
It doesn't matter, and that's the point. Every institution's login method is entirely its own business. One side can run Google SSO, the other can run a legacy SAML system, and a third can still use plain internal accounts with a password. Roaming asks one question only: which institution does this person belong to. Whatever method that institution uses to confirm it is theirs to choose, not ours, and not their partner's.
"How does it actually work behind the scenes, and should we trust ISN with our SSO settings?"
Here's the honest version, not the marketing one.
When a visitor types their identifier at a partner's login page, we don't authenticate them there. We redirect them back to their OWN institution's sign in, the real one, hosted the way it always has been. They log in exactly as they would at home. Their real institution verifies them, not us.
What comes back to the visited institution isn't a password, isn't a session, isn't a token they could reuse anywhere else. It's a single use, short lived proof of identity that expires in minutes and can never be replayed. The visited institution never sees the visitor's credentials, and the home institution never sees where the visitor is browsing.
We re-check that the partnership is actually still active, and that the visitor hasn't hit a device limit, at every single step of that handoff, not just once at the start. If anything has changed (a partnership got paused, a cap got reached) the visitor is told plainly on the login page itself. No dead ends, no false hope.
And your SSO configuration itself, your client secrets, your certificates, is encrypted at rest. We hold what's needed to redirect a login request correctly. We never hold what's needed to impersonate one of your students.
Trust in identity infrastructure isn't something you ask for. It's something you build by making every step checkable, and by making sure the institution that actually knows a person is always the one who gets to say yes.
Full technical breakdown for admins: ISN Free WiFi Single Sign-On