How do I set up SAML SSO and RBAC in Redis Cloud for my organization?

Most teams land on SAML SSO and role‑based access control (RBAC) in Redis Cloud after one of two failure modes: too many local admin accounts to manage safely, or no clean way to lock down who can touch production databases versus dev sandboxes. The good news is that Redis Cloud gives you both SAML SSO and granular roles so you can plug into your existing identity provider (IdP) and keep least‑privilege access in one place.

Quick Answer: You configure SAML SSO at the Redis Cloud account level to delegate authentication to your IdP, then map IdP groups to Redis Cloud roles to enforce RBAC. That lets you centralize user lifecycle management, control who can manage billing vs. databases, and keep production Redis secure without manual user sprawl.

The Quick Overview

What It Is: A way to connect Redis Cloud to your enterprise identity provider using SAML, then use RBAC to control what each user can do inside Redis Cloud (from billing and administration to database‑level operations).
Who It Is For: Platform, security, and DevOps teams running Redis Cloud in larger organizations that need single sign‑on, centralized access reviews, and clear separation of duties across environments.
Core Problem Solved: Eliminates local password/account sprawl in Redis Cloud and replaces ad‑hoc permissions with consistent, auditable roles tied to corporate identity and groups.

How It Works

SAML SSO in Redis Cloud delegates login to your IdP: when a user signs in, Redis Cloud redirects them to your IdP, receives a signed SAML assertion, and uses that to create or map the user. RBAC then takes over: based on assigned roles (and optionally IdP group attributes), Redis Cloud decides which actions the user can perform—like managing subscriptions, creating databases, or just viewing metrics.

At a high level, you’ll:

Configure a SAML SSO “application” in your IdP that points to Redis Cloud.
Add the IdP metadata into Redis Cloud and test SSO.
Design and assign Redis Cloud roles (RBAC) and, optionally, map IdP groups to those roles.

1. Prepare your IdP

You’ll first define Redis Cloud as a SAML service provider (SP) in your identity provider:

Create an enterprise app / SAML integration:
- In Okta: “Create App Integration” → SAML 2.0.
- In Azure AD: “Enterprise applications” → “New application” → “Create your own application” → SAML.
- In Google Workspace: “Apps” → “Web and mobile apps” → “Add app” → “Add custom SAML app”.
Set basic SAML config: Redis Cloud will provide the exact URLs in the UI, but expect something like:
- Single sign‑on URL (ACS URL / Recipient): Redis Cloud SAML callback URL.
- Audience URI (SP Entity ID): Redis Cloud SAML entity ID.
- Name ID format: Usually emailAddress or persistent, with the user’s email as the identifier.
Configure SAML attributes / claims: Configure attributes to send with the SAML assertion, such as:
- email → user’s email.
- firstName (or given_name) → user’s first name.
- lastName (or family_name) → user’s last name.
- groups or a custom attribute (for example redis_roles or redis_groups) if you plan to drive RBAC from IdP groups.
Download IdP metadata:
- You’ll typically export an IdP metadata XML or copy:
  - IdP entity ID
  - SSO URL
  - Public X.509 certificate

You’ll plug this information into Redis Cloud in the next step.

Note: Your IdP configuration is part of your security posture. Make sure your SAML app is restricted to the groups that should have access to Redis Cloud, and enforce strong authentication factors in your IdP (MFA, device posture where applicable).

2. Enable SAML SSO in Redis Cloud

In Redis Cloud, you’ll configure SAML under account/security settings (names can vary slightly as the product evolves):

Sign in with an owner/admin account:
- Use a strong password, TLS, and ensure the account is protected—this will be your fallback if SSO misconfiguration locks users out.
Navigate to SSO / SAML settings:
- Go to Account Settings → Security or Single Sign‑On.
- Look for SAML SSO setup.
Enter IdP metadata:
- Paste the IdP entity ID.
- Paste the SSO URL (IdP login URL).
- Upload or paste the IdP X.509 certificate used to sign assertions.
- Optionally configure:
  - Name ID format (if Redis Cloud exposes it).
  - Attribute mappings (which SAML attributes map to email, first name, last name, groups).
Configure SP‑side URLs in your IdP:
- Redis Cloud will show you:
  - Assertion Consumer Service (ACS) URL
  - SP Entity ID / Audience
- Copy those back into your IdP configuration so the trust is symmetrical.
Test SSO with a pilot user:
- Click “Test SSO” or attempt login via SSO with a single non‑critical test account.
- Confirm:
  - The user is redirected to your IdP.
  - They log in successfully and are redirected back to Redis Cloud.
  - Their Redis Cloud profile shows the expected email and name.
- Check logging in both Redis Cloud (if available) and your IdP to verify that the SAML assertion is accepted, and there are no signature or attribute errors.

Warning: Do not immediately force SSO‑only access without testing. Always keep at least one break‑glass local owner account with strong credentials and protected access, in case SSO settings need to be corrected.

3. Decide on your RBAC model

Before wiring roles to SAML, decide how you want to structure access:

Environment‑centric roles: Separate prod, staging, and dev responsibilities.
Function‑centric roles: Separate billing/owner, platform admins, observability only, and application team operators.
Least‑privilege:
- Minimal set of owners.
- Platform team with rights to create/update databases and subscriptions.
- Application teams with only what they need (e.g., view connection info, manage specific databases).
- Read‑only roles for SRE, support, and auditors.

Typical pattern:

Account Owner / Admin:
- Full access: billing, SSO configuration, subscription management, database creation/deletion.
Platform Admin:
- Manage databases and clusters, but limited/no billing capabilities.
Operator / Dev Team:
- Manage specific databases, view metrics, manage configuration within guardrails.
Read‑only / Observability:
- View databases, metrics, and logs; cannot modify configuration or delete resources.

Note: Redis Cloud’s exact role names/permissions can evolve. Always review the in‑product RBAC documentation for the definitive list of roles and allowed actions.

4. Configure RBAC roles in Redis Cloud

Once your role model is clear:

Create or verify roles:
- Go to Account Settings → Roles or Access Control.
- Review built‑in roles and create any custom roles if the product supports them (for example, a role that can manage dev subscriptions but not production).
Assign permissions to roles: For each role, define:
- Scope: Account‑wide vs. subscription‑ or database‑specific.
- Permissions: Examples include:
  - Manage subscriptions (create/delete/resize).
  - Manage databases (create/update/delete).
  - View metrics and logs.
  - Manage API keys.
  - Manage users and roles.
- Save and document each role’s exact capabilities in your internal runbook.
Manually assign roles (initially):
- For your pilot SSO users, manually assign roles to confirm the behavior.
- Validate:
  - A platform admin can create databases and view metrics but not change SSO settings.
  - A read‑only user can see metrics and database configuration but cannot mutate anything.

5. Map SAML groups to Redis Cloud roles (optional but recommended)

For larger organizations, you don’t want to manage roles per‑user in Redis Cloud. Instead, you map IdP groups to Redis Cloud roles:

Standardize IdP groups: In your IdP, create groups that reflect your intended access:
- redis-cloud-owners
- redis-cloud-platform-admins
- redis-cloud-operators-prod
- redis-cloud-operators-dev
- redis-cloud-observers
Add group attribute to SAML assertion: Configure the SAML app to send group information:
- Attribute name: groups or redis_groups
- Attribute value: all groups the user belongs to, or only Redis‑specific groups via filters.
Configure mapping in Redis Cloud: In Redis Cloud SSO settings (if group mapping is supported):
- Map redis-cloud-owners → Account Owner role.
- Map redis-cloud-platform-admins → Platform Admin role.
- Map redis-cloud-observers → Read‑only role.
- For environment‑specific roles (prod vs dev), map each group to roles scoped to those environments where possible.
Test group‑driven role assignment:
- Update a test user’s group membership in your IdP.
- Trigger SSO login and confirm their effective roles in Redis Cloud change accordingly.
- Document how long propagation takes (some IdPs cache tokens; there can be a short delay).

Warning: When mapping groups to powerful roles (Owner/Admin), restrict membership changes in the IdP to a small, trusted set of admins. An accidental group assignment in IdP can translate to full control of your Redis Cloud production resources.

6. Enforce SSO and clean up direct accounts

Once SSO and RBAC are working:

Optionally enforce SSO:
- If Redis Cloud supports it, enable a mode where users must sign in via SSO (except a break‑glass local owner).
- Communicate this change widely: developers, SRE, and security teams need to know that Redis Cloud now uses corporate SSO.
Audit local users:
- List all existing local users.
- For each user:
  - Confirm they have an equivalent SSO identity.
  - Migrate them to SSO.
  - Remove or downgrade their local account as appropriate.
Set up regular access reviews:
- At least quarterly, review:
  - Which IdP groups map to which Redis roles.
  - Membership of those groups.
  - Redis Cloud user list for anomalies (inactive users, external contractors, etc.).

7. Tie SSO and RBAC into your broader Redis Cloud security posture

SAML SSO and RBAC are one part of Redis Cloud’s shared responsibility model:

You are responsible for:
- Security configurations in your Redis databases.
- Security settings in the Redis Cloud admin console (including SSO/RBAC).
- Network‑level protections (IP allowlists, VPC peering where applicable).
- TLS, ACLs, and any application‑level secrets management.
Redis is responsible for:
- Underlying cloud infrastructure security.
- Access controls for Redis Cloud infrastructure, including strong authentication and least‑privilege access for Redis staff.
- Monitoring and responding to cybersecurity threats using available tools and controls.

Review the Redis Cloud security best practices and shared responsibility model:

Security best practices:
https://redis.io/docs/latest/operate/rc/security/
Shared responsibility model:
https://redis.io/docs/latest/operate/rc/security/shared-responsibility-model/

Align your SAML SSO and RBAC configuration with these documents and with your internal policies (for example, how you handle break‑glass accounts, MFA requirements, and audit logging).

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
SAML SSO Integration	Connects Redis Cloud to your IdP for authentication via SAML 2.0	Centralizes authentication, reduces password risk, and lets you enforce MFA and session policies
Role‑Based Access Control (RBAC)	Defines granular roles for owners, admins, operators, and observers	Enforces least‑privilege access and clean separation of duties across teams and environments
IdP Group → Role Mapping	Maps identity provider groups to Redis Cloud roles automatically	Scales access management; adding/removing users from groups instantly updates their permissions

Ideal Use Cases

Best for enterprise SSO rollouts: Because it lets security and platform teams plug Redis Cloud into centralized identity, enforce MFA, and align with compliance requirements (SOC2, ISO, etc.) without one‑off accounts.
Best for multi‑team, multi‑environment setups: Because RBAC allows you to separate production from non‑production access, giving platform teams full control while application teams and SREs get exactly the permissions they need.

Limitations & Considerations

SAML dependency: If your IdP is unavailable or misconfigured, SSO logins to Redis Cloud can fail.
Workaround: Maintain a secure, documented break‑glass owner account with strong credentials and tightly controlled access.
Group/role drift: If IdP groups are loosely managed, you can accidentally assign broad access to the wrong users.
Workaround: Restrict group admin rights and set up regular access reviews to align groups with Redis Cloud roles.

Pricing & Plans

SAML SSO and advanced RBAC are typically available on business/enterprise‑oriented Redis Cloud plans. Exact plan availability can evolve, but as a pattern:

Standard / Team‑oriented plans: Best for smaller teams needing managed Redis Cloud with core features and manual user/role management.
Business / Enterprise plans: Best for organizations needing SAML SSO, granular RBAC, enterprise security features, and alignment with corporate identity and compliance requirements.

To confirm availability and fit for your organization, talk to Redis sales or a Redis expert.

Frequently Asked Questions

Can I require all users to log in via SAML SSO in Redis Cloud?

Short Answer: Yes, you can configure Redis Cloud to use SAML SSO for authentication, and in many cases you can effectively make SSO the default while still keeping a break‑glass local account.

Details: After configuring and validating SAML SSO, you can shift your organization to SSO‑first access. For security and operational safety, keep at least one non‑SSO owner account with strong authentication as a fallback if your IdP is unavailable or misconfigured. Make sure that account is tightly protected and used only for recovery and SSO configuration changes.

How should I structure roles for production vs. development Redis Cloud environments?

Short Answer: Use separate roles (and ideally separate IdP groups) for production and non‑production, and grant production‑level permissions to a much smaller set of users.

Details: A common pattern is:

redis-cloud-owners: full account ownership (very small group).
redis-cloud-platform-admins: manage all databases and subscriptions, including prod.
redis-cloud-operators-prod: limited operations on production databases only, with clear guardrails.
redis-cloud-operators-dev: broader rights on dev/test databases where risk is lower.
redis-cloud-observers: read‑only access for SRE, support, audit.

Map these groups to Redis Cloud roles, scope roles to the right subscriptions/environments where possible, and review memberships regularly as part of your access review process.

Summary

Setting up SAML SSO and RBAC in Redis Cloud lets you treat Redis the way you treat the rest of your critical infrastructure: authentication is centralized in your IdP, permissions are expressed as roles and groups instead of one‑off accounts, and production access is constrained to the people who truly need it. You configure SAML at the account level, define roles that match your operational model, and use IdP groups to keep access scalable and auditable.

That combination—SAML SSO plus RBAC—aligns Redis Cloud with your broader security and compliance posture while keeping the platform usable for developers and SREs who rely on Redis as their fast memory layer for APIs, real‑time workloads, and AI features.

Next Step

Get Started