Tenant Management

Tenant Management in FlowGenX provides a hierarchical structure for organizing API consumers and controlling access through groups. This enables multi-tenant architecture with complete isolation and granular permission management.

Overview

The tenant management system consists of two main components:

1. Groups: Define access permissions (routes, services, methods)
2. Consumers: Users or applications that inherit group permissions

Groups Management

Groups are collections of access permissions that can be assigned to multiple consumers, enabling role-based access control at scale.

Group Types

Creating a Group

Step 1: Basic Information

1. Navigate to ACL Management → Groups
2. Click Create Group
3. Fill in basic details:

Step 2: Route Permissions

Configure which API routes the group can access:

• Route Entry Mode:

  • Catalog: Select from existing API routes
  • Manual: Enter route paths directly

• Route Configuration:

  • Route path (e.g., /api/users, /webhook/orders)
  • HTTP methods (GET, POST, PUT, DELETE, PATCH)
  • Route prefix selection (/api, /webhook, /http-listener, /app-events)

• Deny Routes: Explicitly block specific routes even if allowed by other rules

Step 3: Service Permissions

Grant or deny access to entire services:

• Allowed Services: Services this group can access
• Denied Services: Services explicitly blocked

Step 4: Review & Create

Review all configurations and create the group.

Editing Groups

1. Locate the group in the Groups list
2. Click Edit
3. Modify permissions using the same wizard
4. Changes apply immediately to all consumers in the group

Group Permissions

Groups support granular permission controls:

Route-Level Permissions:

• Allow specific routes with method restrictions
• Deny specific routes (takes precedence)
• Support for wildcard patterns

Service-Level Permissions:

• Allow entire services
• Deny entire services

Method Restrictions:

• Control HTTP methods per route (GET, POST, PUT, DELETE, PATCH)
• Apply different methods to different routes

Best Practices

✓ Use descriptive group names reflecting roles (e.g., api-readers, data-writers) ✓ Create groups for common access patterns, not individual users ✓ Use deny rules sparingly - prefer least-privilege allowed routes ✓ Document group purposes in the description field ✓ Review group memberships periodically ✓ Disable unused groups instead of deleting ✓ Use environment-specific groups for deployment stage isolation

Consumers Management

Consumers represent individual users or applications that access your APIs. Each consumer inherits permissions from assigned groups.

Consumer Properties

Creating a Consumer

Step 1: Basic Information

1. Navigate to ACL Management → Consumers
2. Click Create Consumer
3. Configure:

- Environment (required for new consumers)
- Username (unique identifier)
- Display Name (human-readable)
- Email, Department, Custom ID (optional)
- Tags (for organization)
- Auto-generate API Key (optional)

Step 2: Group Assignment

Assign the consumer to groups:

1. Search for groups by name
2. Click to add groups
3. Remove groups as needed
4. Groups are applied immediately

Step 3: Review & Create

Review all settings and create the consumer.

Managing Consumer Credentials

API Keys:

• View all API keys for the consumer
• Create new keys directly from consumer view
• Show/hide key values
• Delete keys

OAuth Clients:

• View all OAuth clients
• Create OAuth clients from consumer detail
• Show/hide client IDs and secrets
• Delete OAuth clients

Consumer Lifecycle

Active Consumers:

• Can authenticate with API keys or OAuth tokens
• Inherit all permissions from assigned groups
• Changes to group permissions apply immediately

Inactive Consumers:

• Cannot authenticate (all credentials disabled)
• Useful for temporary suspension
• Can be reactivated without losing configuration

Deleting Consumers:

• Permanently removes consumer and all credentials
• API keys and OAuth clients are invalidated
• Cannot be undone

Filtering and Search

Find consumers quickly:

• Search: Filter by username, display name, email, or department
• Status Filter: Active or Inactive
• Department Filter: View consumers by department
• Environment Filter: Filter by deployment environment
• Pagination: Navigate large consumer lists

Consumer Statistics

View quick stats in the consumer list:

• Total API keys
• Total OAuth clients
• Assigned groups count
• Last activity timestamp

Best Practices

✓ Use meaningful usernames reflecting user/application identity ✓ Always provide display names for human readability ✓ Use department field for organizational reporting ✓ Tag consumers for easy filtering and categorization ✓ Assign consumers to groups, not individual routes ✓ Use custom IDs to link with external systems ✓ Disable consumers instead of deleting for temporary access removal ✓ Review consumer permissions regularly ✓ Document purpose in display name or tags

Group-Consumer Relationship

Permission Inheritance

graph TD
    A[Group 1: API Readers] -->|Assigned to| C[Consumer: mobile-app]
    B[Group 2: Data Writers] -->|Assigned to| C
    C -->|Inherits| D[Combined Permissions]
    C -->|Issues| E[API Key]
    C -->|Issues| F[OAuth Client]
    E -->|Uses| D
    F -->|Uses| D

How it works:

1. Groups define allowed/denied routes and services
2. Consumers are assigned to one or more groups
3. Consumer inherits union of all group permissions
4. Deny rules take precedence over allow rules
5. API keys and OAuth tokens validate against combined permissions

Managing Assignments

Add Consumer to Group:

1. Edit consumer
2. Go to Groups step
3. Search and add groups
4. Save changes

Remove Consumer from Group:

1. Edit consumer
2. Go to Groups step
3. Click remove on group
4. Save changes

View Group Members:

1. Go to Groups section
2. Click on a group
3. View all assigned consumers

Dynamic Updates

Permission changes are dynamic:

• Group Permission Change: Affects all consumers in that group immediately
• Consumer Group Assignment: New permissions apply instantly
• Deny Rule Addition: Blocks access in real-time

Environment Isolation

Environment Features:

• Groups created in one environment don't appear in others
• Consumers are environment-bound
• API keys and OAuth clients respect environment boundaries
• Filter by environment to manage each stage separately

Benefits:

• Prevent accidental cross-environment access
• Test access controls in staging before production
• Separate credentials per environment
• Independent permission management

Common Use Cases

Team-Based Access

Create groups for teams:

• engineering-team: Full API access
• analytics-team: Read-only access
• external-partners: Limited endpoint access

Application-Based Access

Organize by application type:

• mobile-apps: Mobile-specific routes
• web-frontends: Web UI routes
• internal-services: Service-to-service communication
• third-party-integrations: External partner access

Environment-Specific Access

Different permissions per environment:

• Development: Full access for testing
• Staging: Production-like with extended logging
• Production: Restricted to approved routes only

Compliance Scenarios

Create groups for audit requirements:

• pci-compliant: Payment processing routes only
• hipaa-compliant: Healthcare data routes
• gdpr-compliant: EU data processing endpoints

Troubleshooting

Consumer Cannot Access Route

1. Check consumer status (must be active)
2. Verify group assignments
3. Review group permissions for the route
4. Check for deny rules blocking access
5. Confirm environment matches
6. Validate API key/OAuth client is active

Group Changes Not Reflecting

1. Allow a few seconds for propagation
2. Check Kong gateway sync status
3. Verify consumer is assigned to the group
4. Ensure group is active
5. Test with new API request

Permission Conflicts

Multiple Groups with Deny Rules:

• Deny rules from any group take precedence
• Review all assigned groups for deny rules
• Remove conflicting deny rules or reassign groups

Overly Restrictive Permissions:

• Ensure consumer is assigned to correct groups
• Verify group has required route permissions
• Check method restrictions match request type

Environment Mismatch

• Consumers see only groups in their environment
• Ensure group and consumer are in same environment
• Use environment filter to verify