This article explains how SAML single sign-on (SSO) works with app.rewind.com, how access is controlled using the rewind_role attribute, and what to expect once SSO is enabled for your organization. It also links to the setup guide, covers common troubleshooting scenarios, and answers frequently asked questions about using SSO with Rewind.
Covered in this article:
- Provisioning and authentication
- Configuring user access with the rewind_role attribute
- Troubleshooting
- FAQ
Provisioning and authentication
Rewind supports SAML 2.0–based single sign-on (SSO) for accessing app.rewind.com. Users authenticate through your identity provider (IdP), and Rewind relies on the SAML attributes sent by your IdP to determine user access.
Supported identity providers
Rewind supports any identity provider that implements the SAML 2.0 standard. This includes common platforms such as Okta, Microsoft Entra ID, and Google Workspace, as well as other SAML-compatible IdPs.
User provisioning
Rewind uses just-in-time (JIT) provisioning. The first time a user signs in through your IdP, Rewind automatically creates their user account (if one does not already exist) and associates it with your organization.
Rewind does not currently support SCIM for automated provisioning or de-provisioning. User access is managed entirely within your identity provider (IdP).
Users must be assigned to the Rewind SAML application in your IdP in order to sign in. If a user is not assigned to the application, they will not be able to access Rewind—even if SSO is configured for your organization.
If SSO is already configured and you just need to assign access for another user, complete Step 4 and Step 5 in the setup guide.
Authentication flow (SP-initiated only)
Rewind supports service provider (SP)–initiated authentication only. Users must start the login process from app.rewind.com.
- Go to app.rewind.com.
- Select Sign in with SSO instead.
- Enter your company email address.
- Authenticate with your identity provider.
Launching Rewind directly from an IdP dashboard tile or application may not work, since authentication must begin from app.rewind.com.
https://app.rewind.com/auth/cognito?domain={your-domain}. Replace {your-domain} with your organization’s email domain (for example, yourcompany.com).Configuring user access with the rewind_role attribute
Rewind uses Role-Based Access Control (RBAC) to determine what users can see and do within your Rewind organization. When SAML SSO is enabled, roles are assigned through a SAML attribute called rewind_role, which you configure and send from your identity provider (IdP).
The value of this attribute defines which platforms, accounts, and permission levels a user receives when they sign in. If rewind_role isn’t mapped (or isn’t being sent), users may be unable to access Rewind after authenticating.
Understanding role attribute values
Before configuring your IdP, decide which roles you want to assign to your users. Each role determines the level of access a user receives within Rewind.
You configure this value in your IdP as a custom SAML attribute named rewind_role, then assign the appropriate value to each user.
The rewind_role attribute uses the following format: <scope>:<identifier>:<access_level>
| Role | Description |
|---|---|
organization:admin |
Full access to the entire Rewind organization. All other roles are ignored if this is assigned. |
platform:<platform>:admin |
Admin access to all accounts of a specific platform. |
platform:<platform>:read_only |
Read-only access to all accounts of a specific platform. |
account:<account_guid>:admin |
Admin access to a specific account. |
account:<account_guid>:read_only |
Read-only access to a specific account. |
Note: For multiple roles, separate with commas, no spaces: platform:jira:admin,platform:github:read_only
| |
For a granular breakdown of the permissions granted to each role, see Guide to user roles and permissions in Rewind (role-based access control).
Supported values for <platform> include: jira, confluence, bitbucket, monday, azuredevops, klaviyo, mailchimp, miro, okta, entra, github, quickbooks, bigcommerce, shopify, trello
Examples
| Rewind_role value | Access granted |
|---|---|
organization:admin |
Full admin access to everything |
platform:jira:admin |
Admin access to all Jira accounts |
platform:github:read_only |
Read-only access to all GitHub accounts |
account:acc_a1b2c3d4:admin |
Admin access to one specific account |
platform:jira:admin,platform:github:admin |
Admin access to all Jira and GitHub accounts |
How Rewind resolves role conflicts
If a user is assigned multiple roles, Rewind applies a set of rules to determine the final access level.
- If
organization:adminis assigned, it overrides all other roles and grants full access to the entire organization. - If both
adminandread_onlyroles exist for the same platform, theadminrole takes precedence. - If
adminexists for one platform andread_onlyfor another, access is reduced toread_onlyfor both platforms.
Recommendation: Assign a single, clear role per user whenever possible to avoid unexpected access behavior.
Once you understand how authentication and role-based access control work with Rewind, follow the setup guide to configure SAML SSO for
app.rewind.com: Set up SAML single sign-on (SSO) for app.rewind.com →
Troubleshooting
If you’re seeing an error during login or after authentication, the sections below cover the most common causes.
SAML errors
“SAML assertion invalid” or “Invalid signature”
- Re-copy your metadata (XML file or metadata URL) from your IdP and send it to help@rewind.com.
- Verify the metadata URL (if used) is publicly accessible (try opening it in an incognito/private browser).
“User not found” after SSO redirect
- Confirm required attributes are mapped and being sent exactly as:
email,firstName,lastName,rewind_role(case-sensitive). - Verify the
emailattribute maps to the user’s email (for example:user.email). - Take a screenshot of your attribute mappings and send it to help@rewind.com.
“Access denied” or user cannot log in
- Verify the user is assigned to the Rewind application in your IdP.
- Confirm the user’s email domain matches a domain configured for SSO in Rewind.
Role-related issues
User sees “Access denied” or wrong accounts after login
- Check the user’s
rewind_rolevalue in their IdP profile. - Verify the role format matches:
<scope>:<identifier>:<access_level> - For account-level roles, confirm you’re using the correct account GUID (contact help@rewind.com).
Role attribute not being sent
- Confirm a
rewind_roleattribute exists in your IdP user profile. - Confirm your SAML attribute mapping includes
rewind_roleand the mapped source field contains a value. - If the attribute was just added, ensure it’s assigned/published so it appears for users.
User has more access than expected
- Check for
organization:admin— this overrides all other roles. - Review the role conflict resolution rules above.
- Simplify to a single role temporarily to verify expected behavior.
Still having trouble?
If the steps above don’t resolve the issue, contact help@rewind.com and our support team will be happy to help you troubleshoot the issue. To help us troubleshoot more efficiently, include the following details in your message:
- A screenshot of the error message the user encounters during login.
- The full redirect URL shown in the browser after the authentication error occurs.
- A screenshot of your SAML attribute mappings in your IdP.
- The
rewind_rolevalue assigned to the affected user. - The email address of the user experiencing the issue.
FAQ
Which version of SAML does Rewind support?
Rewind supports SAML 2.0.
What if a user already has a Rewind account?
On their first SSO login, if the user already has an email/password account in Rewind, they’ll be prompted to confirm their existing password once to link the accounts. After linking, SSO works normally and the password prompt won’t appear again.
Do you support IdP-initiated login?
No. Users must start at app.rewind.com, choose Sign in with SSO instead, and enter their email. Launching Rewind directly from an IdP dashboard tile may not work.
Can SSO users reset their password in Rewind?
No. SSO users are redirected to the SSO login flow when attempting a password reset. Authentication is handled by your IdP.
Can I still invite users from Rewind?
No. Once SSO is enabled, user access is managed within your IdP. Assigning/removing access in the IdP controls who can authenticate.
Can I remove users from the Member Permissions screen in Rewind?
Yes. This is a visual/organizational change within Rewind. Authentication access is still controlled by your IdP.
Can I enable SSO for just one account?
SSO is configured at the email domain level and tied to your Rewind organization. A single organization can contain multiple accounts, and SSO applies to all of them based on the configured domain(s).
Can I have multiple email domains?
Yes. Provide all domains you want SSO-enabled when setting up with Rewind.
How do I transfer ownership if SSO is enabled?
Self-serve ownership transfer isn’t available with SSO enabled. Contact help@rewind.com with the current owner’s email and Support PIN.
Can Rewind help me configure my IdP?
We’re happy to help with Rewind-side setup and validation. For IdP-specific console steps (for example, where to find a metadata URL), your IdP’s documentation and support team will usually be the fastest path.
Need help?
If you have questions or need assistance, reach out to help@rewind.com or submit a request. We’re here to help!