Identity, SSO & RBAC
Relevant source files
The following files were used as context for generating this wiki page:
The AI Network Operations Platform provides a secure, self-hosted environment for network engineering teams to manage multi-vendor infrastructure using natural language. It centralizes control over authentication (verifying who you are) and authorization (verifying what you are allowed to do), ensuring that every sensitive network change is audited and requires human approval.
Sources: README.md:3-8, CLAUDE.md:3-10
Overview
For a network operations team, this platform solves the problem of managing disparate vendor interfaces and complex automation scripts by acting as an AI Network Engineer. It provides a single point of entry for discovering devices, troubleshooting routing or firewall issues, and managing DDI (DNS, DHCP, and IPAM) across a wide range of hardware and cloud providers.
Supported Vendors and Protocols
The platform connects to your infrastructure using standard methods like SSH, SNMP, and APIs. Supported vendor families include:
- Routing/Switching: Cisco (IOS, IOS-XE, NX-OS), Juniper JunOS, Arista EOS.
- Security: Palo Alto PAN-OS, Fortinet FortiOS.
- Application & Cloud: F5 BIG-IP, AWS, Azure, VMware.
- DDI: BlueCat, Infoblox.
Sources: CLAUDE.md:14-30, README.md:15-18
Design Philosophy
The platform is built on four core principles to ensure it is "enterprise-ready":
- Self-Hosted & Local-First: All data and AI reasoning stay within your network. No traffic leaves your environment unless you explicitly configure an external LLM provider.
- Human-in-the-Loop: While the AI can draft changes, it cannot execute them without a second human approving the request.
- Auditable: Every decision made by the AI and every action taken is logged for compliance.
- Explainable: The AI provides the rationale behind its routing decisions and troubleshooting steps.
Sources: CLAUDE.md:46-55, README.md:4-8
Specialist Team Members (Agents)
The platform uses "Specialists" to handle specific tasks. Think of these as different members of your NetOps team that the Master Architect (the supervisor) routes your questions to:
- Discovery Specialist: Enumerates and lists your inventory.
- Troubleshooting Specialist: Diagnoses live faults like BGP flaps or routing issues.
- DDI Specialist: Handles DNS records and DHCP scope management.
- Configuration Specialist: Narrates config drift and compliance status.
- Security Specialist: Audits firewall policies for hygiene (e.g., shadowed rules).
- Consultant Specialist: Asks clarifying questions if your request is too vague.
Sources: backend/app/llm/prompts/init.py:228-300, backend/app/agents/consultant/agent.py:73-80
Architecture
The platform consists of seven main components that work together to provide a secure and responsive experience for network engineers.
| Component | Description |
|---|---|
| Frontend | The visual console where you chat with the AI, view the topology map, and approve changes. |
| API | The main gateway that handles user login, session management, and coordinates between the UI and the backend. |
| Worker | The background engine that runs discovery jobs, takes config backups, and captures packets without blocking your session. |
| Postgres | The primary database that stores the "system of record," including device inventory, audit logs, and user data. |
| Neo4j | A living topology map that tracks how every device, interface, subnet, and application connects to everything else. |
| Redis | A high-speed queue and cache that helps the API and Workers communicate efficiently. |
| Ollama | An optional local engine that runs the AI models entirely on your own hardware. |
Sources: README.md:10-18, deploy/docker/README.md:10-18
Vendor Connectivity
The platform uses a standardized connector for each vendor. No matter whether you are talking to a Cisco router via SSH or a BlueCat Address Manager via API, the platform normalizes the output into a consistent format before doing anything with it. This allows the AI to reason about your network without needing to understand every vendor's specific CLI syntax.
Sources: README.md:19-22, backend/app/plugins/vendors/cisco_nxos/parsers.py:11-20
Deployment Options
- Docker Compose: Ideal for labs or small teams. It runs the entire stack on a single server using a simple configuration file.
- Kubernetes & Helm: The production-grade option. It supports high availability (multi-node setups), automated backups using pgBackRest, and advanced security features like mutual TLS (mTLS) for database connections.
Sources: deploy/docker/README.md:1-8, deploy/kubernetes/netops/README.md:8-15
System Flows
Platform Connectivity
The following diagram shows how a network engineer interacts with the platform and how the platform connects to external infrastructure and identity providers.
Sources: README.md:10-18, CLAUDE.md:14-30
Agent Routing Workflow
When you send a message, the Master Architect evaluates your goal and routes it to the correct specialist.
Change Approval Workflow
Safety is maintained through a rigorous write-path. No specialist can change the network directly; they only "propose" changes.
Authentication & Configuration
The platform supports local administrative users and Single Sign-On (SSO) via OpenID Connect (OIDC).
Initial Setup
On the first run, the system must be initialized with an administrative password.
# Apply database migrations to set up users and roles
docker compose exec api alembic upgrade head
# The admin user is created using the NETOPS_ADMIN_PASSWORD from your .env file
Sources: deploy/docker/README.md:55-65
Configuration Parameters
These environment variables control how Identity and SSO behave.
| Variable | Type | Description |
|---|---|---|
NETOPS_SECRET_KEY | String | Used to sign security tokens (JWT) for user sessions. |
NETOPS_ADMIN_PASSWORD | String | Sets the initial password for the 'admin' account. |
NETOPS_CORS_ORIGINS | JSON List | Controls which web addresses are allowed to talk to the API. |
Sources: deploy/docker/README.md:45-55, CLAUDE.md:135-145
Identity & RBAC Logic
The system uses the Master Architect to enforce logic-based routing and ensure users are interacting with the correct agent for their role. For example, if a user asks to "Execute an approved change," the platform ensures this routes to the Automation Agent, which is the only specialist allowed to perform write operations after an approval has been granted.