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

Most teams hit the same wall with Redis Cloud security: local users and ad‑hoc roles work for a small squad, but they don’t scale when you need central identity, just‑enough access, and clean off‑boarding. That’s exactly where SAML SSO and role-based access control (RBAC) come in. Together, they let you plug Redis Cloud into your identity provider (IdP) and enforce least-privilege access across projects, databases, and environments.

Quick Answer: In Redis Cloud, you configure SAML SSO at the account level to delegate authentication to your IdP, then use RBAC to grant fine‑grained permissions to users and groups. The combo gives you centralized sign‑in, stronger security, and cleaner operational control over who can touch what.

The Quick Overview

What It Is: A combination of SAML‑based single sign-on (SSO) and role-based access control (RBAC) for Redis Cloud, so your users log in via your IdP and get scoped permissions inside Redis Cloud.
Who It Is For: Platform teams, security engineers, and SREs running Redis Cloud in organizations that use identity platforms like Okta, Azure AD, Google Workspace, or similar.
Core Problem Solved: Eliminates password sprawl and over‑privileged users by centralizing identity in your IdP and managing least-privilege access through well-defined roles and groups.

How It Works

Redis Cloud follows a shared responsibility model: Redis secures the underlying infrastructure, while you’re responsible for account configuration, identity, and access controls. SAML SSO and RBAC live squarely in your side of that model.

At a high level:

Your IdP authenticates users and sends SAML assertions to Redis Cloud.
Redis Cloud consumes those assertions, maps users/groups to internal roles, and grants access accordingly.
RBAC then enforces what each authenticated user can see and do—per account, subscription, project, or database—without you ever managing individual passwords.

Think of SAML SSO as “Who are you?” and RBAC as “What are you allowed to touch?” You wire them together once, then manage day‑to‑day access via your IdP and Redis roles instead of one‑off invites.

1. Prepare Your Identity Provider (IdP)

Before you touch Redis Cloud, you need a SAML app in your IdP. The exact UI steps vary, but the pattern is the same for Okta, Azure AD, Google Workspace, and others.

Create a new SAML app:
- Name it something obvious like Redis Cloud – Production.
- Set the SAML 2.0 protocol.
Configure basic SAML settings (placeholders until you get Redis URLs):
- Entity ID / Audience URI: Will be your Redis Cloud SAML entity ID.
- Assertion Consumer Service (ACS) URL: Will be the Redis Cloud SSO endpoint.
- NameID format: Usually emailAddress.
Decide on attributes & groups:
- Map NameID to the user’s primary email (this must match the email you use in Redis Cloud).
- Optionally include a groups or roles attribute to drive role mappings later.
Assign users and groups:
- Add your platform/security admin group first (so you can recover if something goes wrong).
- Add a small pilot group for testing before you roll this to everyone.

You’ll come back to fill in the final ACS and entity IDs once you’ve configured the SAML connection in Redis Cloud.

2. Enable SAML SSO in Redis Cloud

Now, wire Redis Cloud to your IdP using the SAML metadata exchange.

Sign in to Redis Cloud as an existing account admin.
Navigate to account-level security / SSO settings:
- Go to the organization/account settings area.
- Look for Single Sign-On, SAML, or Identity settings.
Create a new SAML configuration:
- Paste in your IdP’s SAML metadata:
  - IdP Entity ID / Issuer
  - Single Sign-On URL
  - X.509 certificate (used to validate SAML signatures)
- Set NameID to email or emailAddress to match user emails in Redis Cloud.
Configure Redis Cloud SAML details:
- Redis Cloud will generate:
  - Service Provider (SP) Entity ID
  - ACS / SSO endpoint URL
- Copy these back into your IdP’s SAML app configuration:
  - Set Audience/Entity ID to the SP Entity ID from Redis Cloud.
  - Set ACS URL to the Redis Cloud SSO endpoint.
Set the SSO enforcement mode:
- Start in a “SSO optional” or “mixed” mode if available:
  - Users can still sign in with their existing Redis Cloud credentials while you test.
- Only move to “SSO required” once you’ve verified admin access through SAML.

Warning: Don’t enforce SSO-only login until at least two account admins have successfully logged in via SAML and confirmed they can manage subscriptions, projects, and roles. Otherwise you risk locking yourself out.

3. Test the SAML Flow End-to-End

Before you roll this out, verify the full sign-in loop:

IdP-initiated SSO test:
- From your IdP, click the Redis Cloud SAML app.
- Confirm you’re redirected to Redis Cloud without a password prompt.
- Check that the correct account/subscriptions are visible.
SP-initiated SSO test:
- Go to the Redis Cloud login page.
- Click Sign in with SSO or similar.
- Enter the email of a user who’s assigned the SAML app in your IdP.
- Confirm you’re redirected to your IdP, then back to Redis Cloud.
Attribute sanity check:
- Verify the signed-in user’s email in Redis Cloud matches what your IdP sends.
- If you’re using group-based mappings, confirm the right groups are being passed.

Once this works reliably for admins and a small pilot group, you’re ready to layer on RBAC.

Phase by Phase: Wiring RBAC to SAML SSO

RBAC in Redis Cloud is about mapping users and groups to predefined roles and scopes so they only get the access they need.

Design your access model (roles & scopes).
Create roles in Redis Cloud.
Map IdP users/groups to those roles.

1. Design Roles and Scopes

Start from your architecture and environments, not from Redis screen labels. Common patterns:

By environment:
- prod-admins, staging-admins, dev-readers.
By responsibility:
- platform-admins (full control), observability-readers, DBA-ops, AI-feature-devs.
By business unit:
- payments-prod-ops, marketplace-sre, analytics-read-only.

For each role, decide:

Scope: Account-wide, subscription-specific, project-specific, or database-level.
Permissions: Can create/delete databases? Change plans? View metrics only? Manage access?

Note: In a Redis Cloud shared responsibility model, you’re explicitly responsible for “the security configurations in your Redis databases and the Redis Cloud Services admin console.” RBAC is your main tool to enforce that.

2. Create Roles in Redis Cloud

In the Redis Cloud console:

Go to Access control / Roles.
Define a new role for each access pattern:
- Give it a clear name and description.
- Select the permissions:
  - Read-only: View databases, metrics, and logs but no config changes.
  - Operator: Create/scale databases, manage configurations, but not billing.
  - Admin: Full control over subscriptions, billing, and user/role management.
Scope the role:
- Choose whether this role applies to all subscriptions or specific ones.
- Limit to production subscriptions when you’re creating sensitive roles like prod-admin.

Where possible, favor fewer roles with clear meaning over dozens of micro-roles your team won’t remember.

3. Map IdP Groups to Redis Roles

Once roles exist, connect them to your IdP identities.

You have two main patterns:

Direct user assignment: Useful for early pilots but doesn’t scale.
Group-based mapping (recommended): Your IdP group membership controls roles in Redis Cloud.

Typical workflow:

In your IdP:
- Create groups like:
  - redis-cloud-platform-admins
  - redis-cloud-prod-ops
  - redis-cloud-read-only
- Assign users to these groups based on job function and environment.
In your IdP SAML app configuration:
- Add a group attribute, e.g.:
  - Attribute name: groups
  - Value: list of group names or IDs.
In Redis Cloud SAML / SSO settings:
- Define attribute mappings:
  - Map the groups attribute to Redis role assignments.
  - Example:
    - IdP group redis-cloud-platform-admins → Redis role PlatformAdmin
    - IdP group redis-cloud-prod-ops → Redis role ProdOperator
    - IdP group redis-cloud-read-only → Redis role GlobalReadOnly
Validate with a test user:
- Put a test user in one group at a time.
- Log in via SSO and confirm they only see and can only do what the mapped role allows.

Warning: Avoid giving your broad IdP groups (like “All Employees”) any high-privilege roles in Redis Cloud. Use small, purpose-built groups to keep blast radius tight.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
SAML 2.0 Single Sign-On	Delegates Redis Cloud authentication to your IdP using signed SAML assertions.	Centralized login, no separate Redis passwords to manage.
Role-Based Access Control	Scopes permissions by role and resource (account, subscription, project, db).	Least-privilege access and cleaner separation of duties.
Group-to-Role Mapping	Connects IdP groups to Redis Cloud roles automatically.	Access changes follow HR/IdP updates, simplifying onboarding/offboarding.
Shared Responsibility Model Alignment	Gives you controls for the parts you own—console access and database configuration.	Clear security boundaries and auditability for compliance teams.

Ideal Use Cases

Best for production Redis Cloud deployments: Because SAML SSO and RBAC let you enforce strict access boundaries between production, staging, and development—critical when a misclick could impact live traffic or AI workloads.
Best for regulated or audited environments: Because IdP-backed SSO combined with granular RBAC supports compliance requirements around access control (who can touch which data and systems, and how that’s controlled and audited).

Limitations & Considerations

Misconfiguration risk: If you enforce SSO-only login without ensuring at least two admin users can authenticate via SAML, you can effectively lock yourself out of account management.
- Workaround: Keep a break-glass local admin or test in mixed mode before enforcement.
IdP dependency: If your IdP is down or misconfigured, SSO-based login will fail.
- Workaround: Have an incident runbook that includes IdP status checks and a plan for temporary alternate access (according to your organization’s security policies).

Pricing & Plans

SAML SSO and advanced RBAC are typically available on higher Redis Cloud plans aimed at organizations with security and compliance requirements.

Standard / Pro tiers: Best for teams that need managed Redis performance with basic user management and are just starting to centralize access.
Enterprise tiers: Best for organizations that require SAML SSO, advanced RBAC, dedicated VPCs, and alignment with security assessments and shared responsibility expectations.

For exact feature availability and pricing, talk to Redis so you can align your plan with SSO/RBAC needs and your deployment model (cloud, on‑prem with Redis Software, or hybrid).

Frequently Asked Questions

Do I need SAML SSO to use RBAC in Redis Cloud?

Short Answer: No, but they work best together.

Details: You can define roles and assign them to local Redis Cloud users without SAML. That’s helpful for small teams or early-stage projects. However, as your organization grows, managing users and roles manually doesn’t scale and increases off‑boarding risk. Adding SAML SSO lets you push identity and group membership into your IdP, so role assignments follow HR changes automatically. For most production environments, you’ll want both.

How does this relate to Redis Cloud’s shared responsibility model?

Short Answer: SAML SSO and RBAC are central to the parts you’re responsible for—console access and database configuration.

Details: Redis Cloud operates under a shared responsibility model: Redis secures the underlying Cloud infrastructure and platform, and you’re responsible for how you configure your Redis databases and admin console. That explicitly includes:

Which users can log in.
Which roles they have.
Which operations they can perform.

By enabling SAML SSO and designing RBAC carefully, you’re fulfilling your side of that responsibility—ensuring that only authorized, authenticated users can make changes to Redis Cloud resources.

Summary

Setting up SAML SSO and RBAC in Redis Cloud is about more than convenience; it’s your main lever for enforcing least-privilege access in a platform that sits directly in front of your most performance‑sensitive and AI‑critical workloads. You configure SAML to hand off authentication to your IdP, design a small set of clear roles, and wire IdP groups to those roles so access follows your org chart and security policies—not ad‑hoc invites.

Once it’s in place, onboarding, off‑boarding, and audits get easier, and you can focus on what Redis does best: acting as the fast memory layer powering real-time APIs, AI agent memory, semantic search, and low-latency data access—without worrying that the wrong person has the keys to production.

Next Step

Get Started