Skip to main content
Glama
dsoziev1

Auth0 User Monitor MCP Server

by dsoziev1

День 18 — Планировщик и фоновые задачи (Auth0 user-monitor)

Отдельный MCP-сервер БЕЗ LLM (чистый код), который работает 24/7: по расписанию (раз в 10 минут) собирает сводку по пользователям тенанта Auth0, кладёт отчёт в SQLite и авто-блокирует подозрительных админов. Сводка отдаётся по запросу мгновенно из БД. Плюс набор скриптов, моделирующих жизненный цикл пользователей (создание → роли/доступ → активность → блокировка → удаление).

Что внутри

Файл

Роль

server.py

MCP-сервер (без LLM) — tools + фоновый планировщик (stdio / --http).

scheduler.py

Фоновый поток: раз в N сек собирает сводку, авто-блокирует подозрительных, пишет в БД.

collector.py

Сбор сводки из РЕАЛЬНОГО Auth0 (users, roles, last_login, fp-логи, доступ к приложениям).

summary_store.py

SQLite-хранилище отчётов.

simulate.py / simlib.py

Скрипты моделирования жизненного цикла пользователей (запускаются вручную).

client.py

Минимальный MCP-клиент для проверки.

auth0_client.py / config.py / logutil.py

Транспорт к Auth0 (с retry на 429, полные HTTP-логи, маскирование секретов).

Related MCP server: m365-audit-mcp

MCP-инструменты (без LLM)

Tool

Что делает

get_user_summary

Последний отчёт из БД (собран по расписанию) — мгновенно, без обращения к Auth0.

collect_now

Собрать свежий отчёт сейчас, сохранить, вернуть (заодно авто-блок подозрительных).

block_suspicious_users

Найти админов с ≥ порога неудачных входов и заблокировать; вернуть id.

list_reports

История отчётов (время + итоги).

set_schedule

Сменить период сбора (сек) и/или порог подозрительности. Сохраняется, действует сразу.

Сводка по пользователю: email, статус (blocked), last_login, logins_count, роли, признак admin, доступ к приложениям (apps), число неудачных входов (failed_logins), флаг suspicious.

Подозрительный = admin-роль И ≥ AUTH0_SUSPICIOUS_THRESHOLD (по умолч. 5) неудачных входов И не заблокирован. Порог и интервал — через env.

Как это «по-настоящему» (анализ осуществимости)

Всё, что можно — реально в тенанте; то, что Auth0 «из коробки» не даёт — решено явно:

Требование

Реализация

Создание / отключение (blocked) / удаление пользователей

✅ напрямую Management API

Роли (выдача/отзыв)

POST/DELETE /users/{id}/roles

last_login (когда логинился)

Реальные входы через ROPG (password-realm grant) → Auth0 проставляет настоящий last_login/logins_count

«Неудачные входы с неправильным паролем»

Реальные fp-логи от ROPG с неверным паролем; коллектор считает их из GET /logs?q=type:fp

«Доступ к приложениям»

В Auth0 нет прямой связи user→app; моделируется списком в app_metadata.sim.apps (+ реальные роли)

Низкий rate-limit dev-тенанта

Retry на 429 с backoff (Retry-After / X-RateLimit-Reset)

Search-индекс q= отстаёт от создания

Списки пользователей берём через обычный GET /users (консистентно), не через q=

Для ROPG скрипт setup создаёт изолированные удаляемые ресурсы: отдельное regular-web приложение day18-simulator (с password-realm grant) и отдельную БД-коннекшн day18-sim-db (включены и симулятор, и M2M-клиент). cleanup всё удаляет. Секрет симулятора лежит в .sim_state.json (в .gitignore).

Запуск

pip install -r requirements.txt
cp .env.example .env        # AUTH0_DOMAIN / CLIENT_ID / CLIENT_SECRET

1. Сервер 24/7 (отдельный процесс):

python3 server.py --http                 # http://127.0.0.1:8766/mcp, планировщик внутри
# короткий интервал для проверки:
AUTH0_SUMMARY_INTERVAL=60 python3 server.py --http

2. Запросы (другой терминал):

python3 client.py --http --call get_user_summary
python3 client.py --http --call collect_now
python3 client.py --http --call block_suspicious_users

3. Смоделировать «видимость» (создаёт реальные демо-объекты в тенанте):

python3 simulate.py scenario     # users + роли + доступ + реальные входы + блокировка
python3 simulate.py list
python3 simulate.py cleanup       # удалить всё: users + connection + app + role

scenario создаёт 6 пользователей: 2 админа (day18-admin1/2) и 4 обычных; выдаёт роли/доступ; делает реальные входы; day18-admin2 получает 6 неудачных входов (станет подозрительным → сервер заблокирует), day18-user3 тоже 6 неудачных, но он НЕ админ → НЕ блокируется; day18-user4 отключается.

Переменные окружения

Env

По умолч.

Назначение

AUTH0_SUMMARY_INTERVAL

600

Период сбора (сек).

AUTH0_SUSPICIOUS_THRESHOLD

5

Порог неудачных входов для подозрительного админа.

DAY18_DB

day18.db

Файл SQLite с отчётами.

Агент (день 18): чат + панель инструментов

Лёгкий LLM-агент, подключённый ТОЛЬКО к монитору дня 18 (без старого Auth0 98-инструментного MCP). Интерфейс — только чат и описание инструментов сервера.

Файл

Роль

web.py

Минимальный веб: чат + панель «🧰 Инструменты MCP-сервера».

chat_agent.py

Простой агент: диалог + function-calling по тулзам монитора (без этапов/инвариантов/памяти).

mcp_client.py

MCP-клиент/мост к монитору (HTTP по URL или stdio).

llm_client.py

Транспорт к DeepSeek (function-calling).

# 1) монитор (24/7) в одном терминале:
python3 server.py --http
# 2) агент-чат в другом:
MONITOR_URL=http://127.0.0.1:8766/mcp uvicorn web:app --reload   # http://127.0.0.1:8000

Примеры запросов в чате: «покажи сводку», «собери сейчас», «заблокируй подозрительных», «меняй расписание на 5 минут». Агент сам вызывает нужный инструмент монитора; под ответом видно 🔧 какой тул был вызван.

Сам MCP-сервер по-прежнему без LLM. LLM использует только агент.

Архитектура (24/7)

                       ┌─ scheduler (поток, раз в N сек) ─┐
client / агент ─MCP─▶ server.py ─▶ collector ─HTTPS─▶ Auth0 Mgmt API
                          │            ├─ users + roles + last_login
                          │            ├─ logs (type:fp) → failed_logins
                          │            └─ auto-block (admin + ≥5) → PATCH blocked
                          ▼
                    summary_store (SQLite)  ◀── get_user_summary читает отсюда

Сервер не использует LLM. Скрипты симуляции — отдельно, их запускают вручную.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Adaptive security for AI agents: assess inputs for prompt injection, scan outputs for credential/PII leaks, teach new attack patterns to semantic memory, harden prompts, and monitor metrics. Runs locally via MCP stdio.
    Apache 2.0
  • A
    license
    A
    quality
    C
    maintenance
    Exposes Microsoft 365 privacy/compliance audit checks as MCP tools, enabling natural language queries about tenant configuration, orphaned documents, Conditional Access policies, DLP policies, and Copilot usage.
    5
    MIT
  • F
    license
    A
    quality
    C
    maintenance
    A secure, read-only MCP server for AI-powered system monitoring. It provides real-time OS metrics, config discovery, and safe log tailing to enable autonomous infrastructure audits without shell access risks.
    4
    1
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables enterprise MCP security auditing through 12 deterministic no-LLM tools for evidence-gated claims, skill/prompt supply-chain audits, token profiling, and server auth-mode checks.
    MIT