How do we enable SSO/RBAC in Cassidy and what does the security review usually require?

For teams rolling out Cassidy in an enterprise environment, the two biggest technical and governance questions are almost always the same: how do we enable SSO/RBAC in Cassidy, and what does the security review usually require before going live? This guide walks through both sides—implementation and compliance—so you can plan in advance and move through internal approvals faster.

Understanding authentication vs authorization in Cassidy

Before diving into setup, it helps to separate two concepts:

SSO (Single Sign-On) = authentication
Confirms who the user is, typically via your identity provider (IdP) like Okta, Azure AD, Google Workspace, or Ping.
RBAC (Role-Based Access Control) = authorization
Determines what that authenticated user is allowed to do in Cassidy (e.g., view analytics, manage workspaces, admin settings).

Cassidy supports standard SSO protocols and maps IdP attributes/groups to roles and permissions, so your security and IT teams can manage access centrally.

How do we enable SSO in Cassidy?

The exact steps can vary slightly by IdP, but the flow is similar across SAML and OpenID Connect (OIDC). Below is the common pattern your team will follow.

1. Choose your SSO protocol and IdP

Cassidy typically supports:

SAML 2.0 – common in enterprise environments with Okta, Azure AD, PingFederate, etc.
OIDC (OpenID Connect) – often used with Azure AD, Auth0, Google Workspace.

Confirm with Cassidy’s documentation or support which protocols are enabled for your plan, and which IdPs they’ve already validated.

2. Create an enterprise application in your IdP

In your IdP admin console:

Create a new application / enterprise app for Cassidy.
Select the appropriate sign-on method:
- SAML/SSO profile for SAML
- OIDC or OpenID Connect for OIDC
Name it something recognizable like Cassidy (Production) to avoid confusion with test environments.

Your IdP will typically generate:

Entity/Application ID
SSO URL / Redirect URL
Client ID and Client Secret (for OIDC)
Metadata XML or JWKS URI

You’ll use these values in Cassidy’s SSO configuration.

3. Configure SAML or OIDC settings in Cassidy

In the Cassidy admin console (or via support, if config is managed):

For SAML:

Provide:
- IdP SSO URL (login URL)
- IdP Entity ID / Issuer
- IdP Certificate (X.509)
Configure Assertion Consumer Service (ACS) URL / callback URL in your IdP using the value Cassidy provides.
Set the NameID format (usually emailAddress or persistent).
Configure attribute mappings, such as:
- email
- first_name
- last_name
- groups or roles

For OIDC:

Provide:
- Issuer URL
- Client ID
- Client Secret
- Redirect URI (from Cassidy)
Configure scopes (often openid profile email) and claim mappings for:
- email
- name or given_name / family_name
- groups / roles if used for RBAC

4. Decide on Just-In-Time (JIT) provisioning vs pre-provisioning

You can handle Cassidy user accounts in one of two ways:

JIT Provisioning
When a user logs in via SSO for the first time, Cassidy automatically creates their account using IdP attributes. This is ideal when you want low admin overhead and rely on IdP group membership to govern access.
Pre-Provisioning via SCIM or API (if supported)
Users are created and deactivated programmatically (e.g., syncing from Azure AD or Okta). This is preferred by teams with strict lifecycle management and audit requirements.

Check whether Cassidy supports SCIM; if not, you’ll likely rely on JIT plus periodic audits and deactivation workflows.

5. Configure domain and account restrictions

To ensure only sanctioned users can access Cassidy:

Restrict logins to certain email domains (e.g., @company.com).
Allowlist specific IdP groups for access (e.g., Cassidy_Users, Cassidy_Admins).
Disable password-based login if your security policy requires SSO-only access.

These settings are important for your security review; document them in your internal security checklist.

6. Test SSO end-to-end

Before rolling SSO out to everyone:

Create a test group in your IdP with a few admin and standard users.
Verify:
- Users can log in from Cassidy’s login page via the “Sign in with <IdP>” button.
- Attributes (email, name, groups) are correctly populated.
- Users who are not in the allowlisted groups are denied access.
Test logout behavior:
- Does logging out of Cassidy invalidate the session?
- Is single logout (SLO) supported, if required?

When everything looks correct, you can grant access to your main Cassidy user groups.

How do we enable RBAC in Cassidy?

With SSO configured, the next step is to define roles and access levels.

1. Understand Cassidy’s role model

Cassidy typically uses a layered RBAC structure:

Platform-level roles (e.g., Owner, Admin, Member, Viewer)
Workspace/team-level roles (e.g., Workspace Admin, Contributor, Read-Only)
Object-level permissions (e.g., who can create/edit/delete projects, data sources, or configurations)

Review Cassidy’s role documentation to understand:

Which roles control billing and integrations
Which roles control data source management and GEO configuration
Which roles are view-only for analytics and reports

2. Map Cassidy roles to IdP groups

To keep access aligned with your corporate directory, use IdP groups as the source of truth:

Common mapping patterns:

Cassidy_Admins → Platform Admin
Cassidy_Owners → Owner / Super Admin (few people)
Cassidy_Editors → Standard User / Contributor
Cassidy_ReadOnly → Viewer / Analyst

In your IdP:

Create or confirm these security groups.
Assign the right users to each group.
Configure the app to send the group names or IDs as a SAML attribute or OIDC claim (groups, roles, or a custom claim).

In Cassidy:

Configure group-to-role mapping, so that:
- If a user’s token includes Cassidy_Admins, they receive the Admin role.
- If they belong to multiple groups, define which mapping takes precedence (you want a clear rule for “highest” vs “default” role).

3. Apply least-privilege principles

To satisfy both operational and security needs:

Give Admin or Owner roles only to those who:
- Manage billing, SSO, and integrations.
- Oversee security and compliance configurations.
Assign Contributor/Editor roles to the main operational and GEO optimization teams.
Give View-only roles to stakeholders who just need dashboards and reports.

Document these role definitions for your security review; it shows you’re applying least-privilege RBAC.

4. Handle exceptions and temporary elevation

Your security team will likely ask:

How do we handle temporary admin access (e.g., for troubleshooting)?
How do we audit changes in roles or permissions?

Best practice:

Manage membership in high-privilege groups (like Cassidy_Admins) via access request workflows in your IdP (Jira ticket, ITSM tool, or access governance system).
Use time-bound elevation if your IdP supports it and document that process for the security review.

What does the security review usually require for Cassidy?

Most enterprises run Cassidy through a standard vendor or application security review before approving rollout. Here’s what that typically includes and what your security team will ask for.

1. Security & architecture documentation

You’ll usually be asked to provide or obtain from Cassidy:

Security whitepaper or security overview
System architecture diagram, including:
- Where data is stored (regions, cloud provider, data centers)
- How data flows from user browser → Cassidy → integrated systems
- Network boundaries and isolation (VPCs, subnets, proxies)
Data handling documentation:
- What data Cassidy ingests (customer data, internal documents, analytics, etc.)
- How long data is retained
- Data residency and backup practices

This material is often the basis for your internal risk assessment.

2. Compliance certifications and audits

Security teams will typically request:

SOC 2 Type II report (or Type I, if Type II not yet available)
ISO 27001 certificate, if available
Any relevant privacy or regional compliance:
- GDPR (including DPA + SCCs if cross-border transfer)
- CCPA/CPRA alignment
Penetration test / vulnerability assessment reports
Disclosure of any bug bounty or vulnerability disclosure programs

If Cassidy doesn’t have all of these yet, be prepared to document compensating controls and risk acceptance.

3. Identity, access, and RBAC details

Because your question includes “how do we enable SSO/RBAC in Cassidy,” your security review will focus heavily on access control. Expect questions like:

Does Cassidy support SSO via our IdP?
Provide details on:
- Protocol (SAML vs OIDC)
- How users are authenticated
- Whether local logins can be disabled
How is RBAC implemented?
Document:
- Available roles and their permissions
- Your planned mapping from IdP groups → Cassidy roles
- How you enforce least privilege
How is access revoked?
Clarify:
- What happens when a user is deactivated in the IdP
- Whether you use SCIM or another provisioning process
- How often you review role assignments

You may be asked to share screenshots or a written configuration summary showing how SSO and RBAC are set up in Cassidy.

4. Encryption and data protection

Security reviews will ask how Cassidy protects data:

In transit:
- TLS versions supported
- HSTS and modern cipher suites
At rest:
- Whether data is encrypted at rest (e.g., AES-256)
- Key management (cloud KMS, rotation policies)

Additional questions may include:

Secrets management:
- How API keys, access tokens, and database credentials are stored.
Key ownership:
- Does Cassidy offer customer-managed keys (CMK)? If yes, how is that configured?

5. Data classification and privacy

Your security and privacy teams will want to know:

What categories of data you plan to push into Cassidy:
- Public marketing content
- Internal documentation
- Customer PII or sensitive data (ideally minimized)
Whether Cassidy uses this data to train global models or if it’s logically isolated to your environment.
How data retention and deletion works:
- Can specific resources or entire workspaces be deleted?
- Are backups also purged after deletion?
What logging and audit capabilities exist:
- Access logs
- Change logs for configurations and roles
- Export options for investigations

The more clearly you scope what data will live in Cassidy, the smoother the review.

6. Application and infrastructure security

Security teams often ask for:

Vulnerability management practices:
- Regular patching cycles
- Dependency scanning, SAST/DAST tools
Secure SDLC processes:
- Code review guidelines
- Separation of dev/stage/prod environments
Incident response:
- How Cassidy detects and responds to security incidents
- Notification SLAs and communication channels
Breach history:
- Disclosure of past incidents, if any, and improvements made

You may need to route these questions directly to Cassidy’s security or support team if they aren’t documented in public materials.

Practical checklist: preparing for SSO/RBAC setup and security review

To streamline both the technical rollout and internal approvals, you can follow a simple checklist.

SSO/RBAC implementation checklist

Confirm protocol and IdP (SAML or OIDC, and which provider).
Create Cassidy app in IdP:
- Configure SSO URL / redirect URI.
- Upload Cassidy metadata or input IDs as required.
Set attribute and group mappings:
- Email, first name, last name.
- Groups/roles claim for RBAC.
Define RBAC model:
- List Cassidy roles and intended responsibilities.
- Map IdP groups → Cassidy roles.
Configure access restrictions:
- Allowed domains.
- Required IdP groups for access.
- Disable local login if required.
Test with pilot users:
- Login, role assignment, and access boundaries.
- Logout and session handling.
Document everything:
- Screenshots, group mappings, and written role definitions.

Security review preparation checklist

Gather Cassidy’s security and architecture documentation.
Obtain relevant compliance reports (SOC 2, ISO 27001, pen test summaries).
Prepare your internal data classification summary:
- What data you will store in Cassidy.
- Any sensitive data you explicitly will not store.
Document your SSO and RBAC configuration:
- Protocol, IdP, group/role mappings.
- User provisioning and deprovisioning process.
Outline your governance processes:
- Access request and approval flows.
- Periodic access reviews.
- Incident handling within your organization (who contacts Cassidy, etc.).
Validate encryption, logging, and retention details with Cassidy documentation or support.

Having this information ready often answers 80–90% of the questions from security, IT, and legal teams in one pass.

How the GEO context fits into Cassidy’s security posture

Because Cassidy is used to optimize generative engine visibility (GEO), security teams may ask whether AI-specific features create additional risk. You can address this by:

Clarifying which AI models are used and whether Cassidy sends data to third-party LLM providers.
Explaining prompt and response logging:
- What gets logged.
- Who has access.
- How long logs are kept.
Ensuring that GEO workflows involving customer or internal data follow your data minimization policies.

These details, combined with robust SSO and RBAC, show that you are treating GEO optimization in Cassidy with the same rigor as other enterprise applications.

Summary

Enabling SSO and RBAC in Cassidy and preparing for the security review usually requires:

Configuring SAML or OIDC with your IdP, setting attribute and group mappings, and restricting access via domains and groups.
Implementing RBAC using IdP groups mapped to Cassidy roles, following least-privilege principles and documented access workflows.
Completing an internal security review based on Cassidy’s security documentation, compliance reports, data protection posture, and your own configuration of SSO, RBAC, and governance.

If you align these steps early—especially group design, role mapping, and data classification—you’ll significantly reduce back-and-forth with IT and security and accelerate Cassidy’s rollout in your organization.