Use this checklist when users can't sign in to a Scroll site with single sign-on, see a SAML authentication error, or are asked to sign in repeatedly.
Use this checklist when users cannot sign in to a Scroll Sites site with single sign-on, see a SAML authentication error, or get stuck in a login loop.
Before you start, open your site in Scroll Sites and go to Site access → Domains & Security → Set up single sign-on. You will need the values shown there to compare against your identity provider settings.
SAML authentication usually fails for one of three reasons: a required value in your identity provider doesn't exactly match the value in Scroll Sites, the signing setup is incomplete, or the identity provider metadata in Scroll Sites is out of date.
Recommended actions
Check the relying party identifier and ACS URL. In your identity provider, confirm that the service provider values exactly match the values shown in Scroll Sites.
-
-
Relying party identifier must match the Entity ID, Audience URI, or Identifier field in your identity provider.
-
Assertion consumer service URL must match the ACS URL, Reply URL, or Single sign-on URL field. Set the Recipient to the same value. Even small differences cause sign-in to fail - a trailing slash, the wrong protocol, or a typo in the domain.
-
Set the Login URL to your Scroll site URL.
-
-
Confirm the signing configuration. Scroll Sites expects both the SAML response and the assertion to be signed. Auth0 and Google are exceptions - they work when only the response is signed.
-
Verify that the user is assigned to the application. In many identity providers, creating the SAML app isn't enough. You also have to assign the correct users or groups before they can sign in.
-
Re-paste the metadata after certificate changes. If your identity provider rotated or regenerated its signing certificate, export the updated federation metadata XML and paste the latest version into Scroll Sites. An outdated certificate prevents Scroll Sites from validating the SAML response.
Download the XML file and copy the metadata from the file itself. Copying it from the browser view can produce metadata that Scroll Sites can't read.
-
Check the site access option. In Scroll Sites, the site access option has to be set to Protected: Single sign-on, and the change has to be published.
If you recently changed your identity provider settings, test in a private browser window. Existing cookies or stale sessions make it harder to tell whether the new configuration works.
If users are asked to sign in again
Repeated sign-in prompts are usually expected behavior rather than a configuration problem. Scroll Sites stores signed values in the browser, and those expire after one hour. The session cookie is also deleted when the browser session ends. In both cases, users have to authenticate again.
Common provider-specific checks
The checks below apply to the identity providers we see most often in support tickets.
|
Identity provider |
What to check |
|---|---|
|
Microsoft Entra ID |
Use the Federation Metadata XML from the SAML Signing Certificate section. Make sure the Identifier and Reply URL match the Scroll Sites values exactly. |
|
Okta |
Confirm the app is assigned to the right people or groups. Set the Single sign-on URL and Recipient to the Scroll Sites ACS URL. |
|
Keycloak |
Create Scroll Sites as a Client. Verify that the client URLs match the Scroll Sites values exactly. |
|
OneLogin |
Set the Recipient to the ACS URL and confirm the Audience matches the relying party identifier. |
|
Auth0 or Google |
Sign the response. These providers do not sign both the response and the assertion, and that is supported. |
What a successful setup should include
-
The Entity ID in your identity provider matches the Scroll Sites relying party identifier exactly.
-
The ACS URL and Recipient in your identity provider match the Scroll Sites assertion consumer service URL exactly.
-
The Login URL points to your Scroll site.
-
The SAML response is signed.
-
The assertion is signed, unless you use Auth0 or Google.
-
The user is assigned to the SAML application.
-
The metadata XML in Scroll Sites includes the current signing certificate.
-
The site access option is set to Protected: Single sign-on, and the change is published.
Still not working?
Collect the following before contacting K15t support:
-
Your Confluence base URL and Site ID
-
The name of your identity provider
-
The exact error shown during sign-in
-
Any recent SAML configuration changes
This tells us whether the cause is metadata, signing, user attributes, or a provider-specific setting.
Related Articles