home / skills / jeremylongshore / claude-code-plugins-plus-skills / posthog-enterprise-rbac

This skill configures PostHog enterprise SSO, RBAC, and organization controls to streamline secure access management.

npx playbooks add skill jeremylongshore/claude-code-plugins-plus-skills --skill posthog-enterprise-rbac

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
5.4 KB
---
name: posthog-enterprise-rbac
description: |
  Configure PostHog enterprise SSO, role-based access control, and organization management.
  Use when implementing SSO integration, configuring role-based permissions,
  or setting up organization-level controls for PostHog.
  Trigger with phrases like "posthog SSO", "posthog RBAC",
  "posthog enterprise", "posthog roles", "posthog permissions", "posthog SAML".
allowed-tools: Read, Write, Edit
version: 1.0.0
license: MIT
author: Jeremy Longshore <[email protected]>
---

# PostHog Enterprise RBAC

## Overview
Configure enterprise-grade access control for PostHog integrations.

## Prerequisites
- PostHog Enterprise tier subscription
- Identity Provider (IdP) with SAML/OIDC support
- Understanding of role-based access patterns
- Audit logging infrastructure

## Role Definitions

| Role | Permissions | Use Case |
|------|-------------|----------|
| Admin | Full access | Platform administrators |
| Developer | Read/write, no delete | Active development |
| Viewer | Read-only | Stakeholders, auditors |
| Service | API access only | Automated systems |

## Role Implementation

```typescript
enum PostHogRole {
  Admin = 'admin',
  Developer = 'developer',
  Viewer = 'viewer',
  Service = 'service',
}

interface PostHogPermissions {
  read: boolean;
  write: boolean;
  delete: boolean;
  admin: boolean;
}

const ROLE_PERMISSIONS: Record<PostHogRole, PostHogPermissions> = {
  admin: { read: true, write: true, delete: true, admin: true },
  developer: { read: true, write: true, delete: false, admin: false },
  viewer: { read: true, write: false, delete: false, admin: false },
  service: { read: true, write: true, delete: false, admin: false },
};

function checkPermission(
  role: PostHogRole,
  action: keyof PostHogPermissions
): boolean {
  return ROLE_PERMISSIONS[role][action];
}
```

## SSO Integration

### SAML Configuration

```typescript
// PostHog SAML setup
const samlConfig = {
  entryPoint: 'https://idp.company.com/saml/sso',
  issuer: 'https://posthog.com/saml/metadata',
  cert: process.env.SAML_CERT,
  callbackUrl: 'https://app.yourcompany.com/auth/posthog/callback',
};

// Map IdP groups to PostHog roles
const groupRoleMapping: Record<string, PostHogRole> = {
  'Engineering': PostHogRole.Developer,
  'Platform-Admins': PostHogRole.Admin,
  'Data-Team': PostHogRole.Viewer,
};
```

### OAuth2/OIDC Integration

```typescript
import { OAuth2Client } from '@posthog/sdk';

const oauthClient = new OAuth2Client({
  clientId: process.env.POSTHOG_OAUTH_CLIENT_ID!,
  clientSecret: process.env.POSTHOG_OAUTH_CLIENT_SECRET!,
  redirectUri: 'https://app.yourcompany.com/auth/posthog/callback',
  scopes: ['read', 'write'],
});
```

## Organization Management

```typescript
interface PostHogOrganization {
  id: string;
  name: string;
  ssoEnabled: boolean;
  enforceSso: boolean;
  allowedDomains: string[];
  defaultRole: PostHogRole;
}

async function createOrganization(
  config: PostHogOrganization
): Promise<void> {
  await posthogClient.organizations.create({
    ...config,
    settings: {
      sso: {
        enabled: config.ssoEnabled,
        enforced: config.enforceSso,
        domains: config.allowedDomains,
      },
    },
  });
}
```

## Access Control Middleware

```typescript
function requirePostHogPermission(
  requiredPermission: keyof PostHogPermissions
) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const user = req.user as { posthogRole: PostHogRole };

    if (!checkPermission(user.posthogRole, requiredPermission)) {
      return res.status(403).json({
        error: 'Forbidden',
        message: `Missing permission: ${requiredPermission}`,
      });
    }

    next();
  };
}

// Usage
app.delete('/posthog/resource/:id',
  requirePostHogPermission('delete'),
  deleteResourceHandler
);
```

## Audit Trail

```typescript
interface PostHogAuditEntry {
  timestamp: Date;
  userId: string;
  role: PostHogRole;
  action: string;
  resource: string;
  success: boolean;
  ipAddress: string;
}

async function logPostHogAccess(entry: PostHogAuditEntry): Promise<void> {
  await auditDb.insert(entry);

  // Alert on suspicious activity
  if (entry.action === 'delete' && !entry.success) {
    await alertOnSuspiciousActivity(entry);
  }
}
```

## Instructions

### Step 1: Define Roles
Map organizational roles to PostHog permissions.

### Step 2: Configure SSO
Set up SAML or OIDC integration with your IdP.

### Step 3: Implement Middleware
Add permission checks to API endpoints.

### Step 4: Enable Audit Logging
Track all access for compliance.

## Output
- Role definitions implemented
- SSO integration configured
- Permission middleware active
- Audit trail enabled

## Error Handling
| Issue | Cause | Solution |
|-------|-------|----------|
| SSO login fails | Wrong callback URL | Verify IdP config |
| Permission denied | Missing role mapping | Update group mappings |
| Token expired | Short TTL | Refresh token logic |
| Audit gaps | Async logging failed | Check log pipeline |

## Examples

### Quick Permission Check
```typescript
if (!checkPermission(user.role, 'write')) {
  throw new ForbiddenError('Write permission required');
}
```

## Resources
- [PostHog Enterprise Guide](https://docs.posthog.com/enterprise)
- [SAML 2.0 Specification](https://wiki.oasis-open.org/security/FrontPage)
- [OpenID Connect Spec](https://openid.net/specs/openid-connect-core-1_0.html)

## Next Steps
For major migrations, see `posthog-migration-deep-dive`.

Overview

This skill configures PostHog enterprise SSO, role-based access control (RBAC), and organization-level settings to secure analytics platforms. It provides role definitions, IdP mapping patterns for SAML/OIDC, middleware for permission enforcement, and audit logging guidance. Use it to standardize authentication, authorization, and compliance workflows for PostHog at scale.

How this skill works

The skill defines canonical roles (admin, developer, viewer, service) and maps each to a concrete permission set (read/write/delete/admin). It includes examples for SAML and OAuth2/OIDC IdP configuration and group-to-role mapping. Middleware hooks enforce permissions on API endpoints and audit entries capture access events for monitoring and alerting.

When to use it

  • Implement enterprise SSO for PostHog with SAML or OIDC
  • Establish RBAC to limit actions by role (delete, write, admin privileges)
  • Automate organization setup with default roles, allowed domains, and SSO enforcement
  • Add permission checks to backend APIs that interact with PostHog resources
  • Enable audit logging and alerting for compliance or security reviews

Best practices

  • Define a small set of clear roles and map IdP groups to them consistently
  • Enforce SSO for organization members to centralize identity and MFA controls
  • Use middleware to centralize permission checks rather than sprinkling logic across handlers
  • Log all access attempts with role, action, resource, and IP for forensic analysis
  • Alert on suspicious events such as failed delete attempts or repeated auth failures

Example use cases

  • Map IdP groups to PostHog roles during SAML onboarding to automate role assignment
  • Create organization template with enforceSso and allowedDomains to restrict accounts to corporate emails
  • Protect destructive endpoints with requirePostHogPermission('delete') middleware
  • Issue service accounts with the service role for automated ingestion pipelines
  • Audit all role changes and failed privileged actions to a security SIEM

FAQ

What IdP options are supported?

SAML 2.0 and OAuth2/OIDC are supported; choose based on your Identity Provider capabilities.

How do I prevent orphaned accounts?

Enable enforceSso and restrict allowedDomains so every user must authenticate via your IdP.

Which role should automated systems use?

Use the service role with API access only; grant minimal write rights and avoid admin/delete privileges.