If you are setting up Security & Settings for the first time, create the pieces in this order. Build policies before roles, and roles before users, so each colleague has the right access when you add them.
Before You Begin
Prerequisites
- Console access that lets you open System & Security.
- Advanced (granular) security enabled for your organization, if you want to create your own security roles and policies. This is separate from portal security, so having portal security does not mean you also have advanced security. To check, open System & Security › Security › Policies or Roles. Rhythm tells you if advanced security is not available, and your Customer Success Manager can help add it. If your organization has more than one Rhythm account, such as a live account and one or more sandboxes, each account may need advanced security enabled separately. Having it enabled in one account does not mean it is enabled in another.
- A sandbox, if your organization has one, so you can test roles, users, and keys before you use them in your live account. Most sandboxes do not automatically have their own identity configuration, so API key testing is not always ready by default. Support may need to set it up manually, and you may also need to request separate admin access to that sandbox's identity configuration before you can test changes there. If the API Keys page in a sandbox fails with an error about being unable to locate settings for your account, missing setup is the likely cause, not a problem with your data.
The Order
- Define your security policies. Decide which reusable permission bundles your organization needs, such as one policy for everyday membership work and another for financial actions. Create them from System & Security › Security › Policies before you build roles that depend on them. See Security Roles, Policies, and Permission Statements. A policy's eligibility rules usually check the record itself rather than a related record, such as a contact's own status instead of a certification held by their organization. Confirm with Support before you rely on a rule that depends on a related record. You can also apply a policy to a specific portal page, such as an event microsite's registration page, so someone who does not meet the policy sees a clear access message instead of reaching the page.
- Define your security roles. Build each named job, such as "membership coordinator" or "event staff," by attaching the policies from step 1, Rhythm-managed policies, and any statements specific to that role. You attach roles to people, so creating roles first gives each new colleague complete access on the day you add them.
- Create your console users and attach roles. Add each colleague as a console user, then attach the role or roles that match their job. Creating the console user gives the person an account, but their access matches your intent only after you assign a role or policy. See Console Users.
- Create partner API keys for any approved external systems. After staff access is settled, issue an API key for each integration you plan to connect. Choose the right kind of key, then give the one-time secret link to the integration owner. See API Keys.
- Verify. Sign in as a newly created console user, or ask them to sign in, and confirm they can access what their role allows and nothing else. For a new API key, confirm the external system can call Rhythm with the secret it received. If you have a sandbox, test there first before you repeat the setup in your live account.
Result
Your association has security policies and roles that match how your organization delegates work. Console users have access that matches their jobs from the day you add them, and API keys are issued only to the approved systems that need them.
Tip
If you create a console user before your roles exist, you will need to build that person's access from individual policies and statements instead of a reusable role. Creating roles first makes the next person with the same job much faster to set up.
Warning
Turning on advanced (granular) security for an organization that already has console users has an immediate effect. If an existing user does not already have a role, policy, or equivalent access assigned at that moment, they can lose access to what they previously used until you attach one. After you enable advanced security, review every existing console user, not just the ones you create afterward. Before you consider the rollout finished, make sure each user has a default account set and a role or policy attached.
Multi-Factor Authentication
Turning on multi-factor authentication (MFA) for your console users is not self-service. Ask Support to submit the request for internal review, and coordinate a specific future date and time for it to take effect because Rhythm enables it for you.
Warning
MFA cannot be enabled only in a sandbox. Once it is turned on, it applies across every related account under your organization, including your live account. Because of that, you cannot fully test the end-user experience in a sandbox first; enabling MFA is the live rollout.
You can ask for a phased rollout that starts with a limited set of users before everyone else is required to use MFA. You can also time the remaining cutover around your association's calendar, such as avoiding your busiest event dates for the users most affected by them. The heading shown on the MFA prompt can likely be customized; ask Support if you want to change it.
Additional Configuration Rhythm Coordinates
A few settings are not self-service, so you need to request and schedule them with Rhythm:
- CAPTCHA can be turned on or off separately for your sandbox and your live account. This lets you test with it disabled in your sandbox, then enable it in production on a specific date. Give Support at least 48 hours' notice for a production change, and confirm which public-facing forms should be in scope, such as registrations, payments, donations, and add-a-credit-card flows.
- Hosted sign-in page branding. If you customize the logo on the hosted sign-in page, Auth0 recommends a logo size of 150 by 150 pixels.
- Single sign-on (SSO). If a vendor's discovery process returns an error when it uses a generic discovery path, you likely need your own account's OIDC discovery document or explicit endpoints instead of a generic one. Ask Support for the correct values for your account. If you need to review how an existing SSO connection was set up, ask Support for the setup documentation for your account.
Going Live
Moving a public-facing sign-in setup from a sandbox to your live account requires several changes to happen together. You need to update your DNS, Rhythm needs to switch your account from sandbox to production mode, and every identity-provider setting that still uses a staging address, including callback URLs, needs to point to your production portal. If you miss the identity-provider update, verification links and sign-in redirects can keep pointing to your staging domain after everything else has gone live.
If You Do Not Have Advanced Security
If your organization does not have advanced (granular) security, steps 1 and 2 are not available. Creating a console user gives that person an identity and the access your plan grants by default, without roles, policies, or individual statements to combine. Steps 3 through 5 still apply.