Your campus has one login for email, the learning management system, and the student portal. Then an editor opens Cascade and is asked for a separate username and password, which they have forgotten since last semester. Single sign-on (SSO) removes that second account. Authors sign in with their campus credentials, your identity team controls who has access, and when someone leaves the institution their access ends with their campus account.
Two places SSO shows up
Institutions usually mean one of two things by "SSO for Cascade", and they are configured in different places.
- Author sign-in to Cascade. Editors authenticate to the Cascade application through your identity provider (IdP) using SAML 2.0, or through LDAP or Active Directory. The Cascade side is configured in Cascade's administration settings. The identity side is configured in your IdP.
- Protected sections of the published site. Some pages, such as an employee intranet or a faculty resources area, should only be visible to signed-in campus users. Because Cascade publishes static files, that protection lives at the web server or CDN, not in Cascade. The hosting layer acts as a SAML service provider in front of those folders.
How a SAML sign-in works
SAML is a trust arrangement between two systems. The service provider (Cascade, or the web server protecting a folder) sends the user to the IdP. The IdP authenticates them, with multi-factor authentication if your policy requires it, and sends back a signed assertion saying who the user is and which attributes they carry. The service provider checks the signature against the certificate it was given and signs the user in. No password ever reaches Cascade.
That arrangement depends on three things staying in agreement: the metadata each side holds about the other, the signing certificates, and the attribute that identifies the user.
Setup checklist
- Exchange metadata. The IdP needs the service provider's entity ID and assertion consumer service URL. The service provider needs the IdP's metadata, including its signing certificate.
- Agree on the identifying attribute. Decide which attribute maps to the Cascade username (often the campus username or email address) and confirm it matches existing Cascade accounts exactly, including case.
- Decide how accounts are created. Either accounts exist in Cascade before first sign-in, or they are created on first sign-in with a default role. Most institutions prefer pre-created accounts so roles and group memberships are deliberate.
- Keep a break-glass account. Maintain at least one local administrator account that does not depend on the IdP, stored securely, so an IdP outage or a certificate problem does not lock everyone out.
- Test with a real user who is not an administrator before switching everyone over.
The five most common SSO errors
| What the user sees | Likely cause | Fix |
|---|---|---|
| Everyone fails at once, starting on a specific day | The IdP signing certificate was rotated and the service provider still trusts the old one | Load the new IdP metadata or certificate on the service provider side |
| Signs in at the IdP, then "user not found" | The identifying attribute does not match the Cascade username | Correct the attribute mapping or the Cascade account name |
| Intermittent "assertion expired" or "not yet valid" | Clock drift between systems | Fix time synchronization; assertions are only valid for a short window |
| Redirect loop between the site and the IdP | Cookie or session problem, often a mismatched URL (http versus https, or www versus bare domain) | Make the service provider URLs match the address users actually visit |
| One person cannot sign in, everyone else can | Account disabled, missing group membership, or MFA enrollment incomplete at the IdP | Check the user's status with your identity team |
Ask your identity team about planned certificate rotations. A rotation that is shared with the service provider owners a few weeks ahead causes no outage at all. One that is not causes the first row of that table.
How eWay handles SSO
eWay configures and manages SSO with SAML 2.0, LDAP, and Active Directory, and works with your identity team on the IdP side. For protected sections of the published site, eWay runs the service provider at the hosting layer so those folders require campus sign-in without any change to how editors publish. eWay monitors certificate expiry on the hosting side and coordinates with your identity team when a rotation is planned. Where a change is needed in Cascade's own settings, eWay coordinates with Hannon Hill.
What to include in a support ticket
- The severity you would assign, P1 to P4 (see severity levels and response times)
- Whether the problem is author sign-in to Cascade or access to a protected part of the website
- Whether it affects everyone or specific users, and one example username
- The exact error text or a screenshot, and the time it happened
- Any recent change on the IdP side, such as a certificate rotation or attribute change
eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: securing a Cascade site and how Cascade publishing reaches your live website. See Cascade Website Hosting for more.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article