Если бы всё так просто было :) я за некоторое время сварил вот такой гайд для код-ревью - Opus как раз успешно пользуется. Вчера дополнил как-раз выжимкой из данной статьи, но тоже пришлось несколько с опусом поругаться, чтобы перепроверил.
похожую задачу описывали в https://habr.com/ru/articles/1022288/ - там же в комментах есть ссылка на мою репу с растовым фреймворком для авторизации для MCP
На самом деле всё порываюсь зарелизить крейт авторизационного слоя для MCP реализующего аутентификацию и авторизацию на пути к функциональному MCP-серверу, но жоска ленюсь - там 100%ный Клод конечно, но очень плотно оттестированный
Клиент логинится через браузер по OAuth 2.1 с PKCE и получает от Keycloak токен, выписанный специально для MCP-сервера. Дальше клиент просто прикрепляет его ко всем своим запросам.
Получив запрос, MCP-сервер берёт этот токен, стучится в Keycloak и меняет его (через token exchange по RFC 8693) на новый, предназначенный уже для конкретной целевой системы. Идентификатор пользователя при этом сохраняется. С этим новым токеном MCP-сервер и идёт в систему, действуя от лица юзера.
Но схема работает, только если конечная система умеет валидировать токены Keycloak. Например, с Jira DC это не прокатило - там пришлось поднимать отдельный OAuth-флоу до самой Джиры и хранить токены индивидуально для каждого пользователя в шифрованном кэше.
Чтобы не положить Keycloak постоянными запросами на обмен, новые токены кэшируются в памяти MCP-сервера. Они лежат там до тех пор, пока до истечения срока их действия (exp) не останется 30 секунд.
Token-exchange в клоке: мой MCP-сервер умеет в OAuth - при подключении авторизуемся через PKCE (через браузер), потом MCP-сервер меняет токен на соответствующий для таргета. Как я понимаю - вам больше первая стадия интересна
сравнивал мельком внутри - разница есть и она в пользу классического bridge (rootful-сценарий), но с другой стороны во всех трёх случаях получал не менее 400Мбит на виртуальных машинах (Proxmox) в тестах с OpenSpeedTest
Соглашусь с комментарием. Да, с podman из коробки значительно проще организовать rootless-сценарии, но в статье виден только некий каркас без наполнения. Где реальные кейсы побега? (да, их действительно хватает - в статье лишь упоминание таковых без подробностей). Автор, расскажи про то как pasta отличается от slirp4netns в части заголовков в пакетах, какие ограничения у pasta есть в плане работы с localhost.
2gotch: rootless-мод в докере мало общего имеет с реализацией в подмане - демон всё-равно болтается :)
Информация
В рейтинге
5 255-й
Зарегистрирован
Активность
Специализация
Системный администратор, Специалист по информационной безопасности
спасибо за фидбек, если будут дополнения дельные - с удовольствием рассмотрю и буду пользовать
Если бы всё так просто было :) я за некоторое время сварил вот такой гайд для код-ревью - Opus как раз успешно пользуется. Вчера дополнил как-раз выжимкой из данной статьи, но тоже пришлось несколько с опусом поругаться, чтобы перепроверил.
похожую задачу описывали в https://habr.com/ru/articles/1022288/ - там же в комментах есть ссылка на мою репу с растовым фреймворком для авторизации для MCP
Опубликовал релиз: https://github.com/andrico21/rmcp-server-kit
GUIDE.md, Recipe 2 - натравите ллмку, будет быстрее понять 😁
На самом деле всё порываюсь зарелизить крейт авторизационного слоя для MCP реализующего аутентификацию и авторизацию на пути к функциональному MCP-серверу, но жоска ленюсь - там 100%ный Клод конечно, но очень плотно оттестированный
Да, всё верно. По сути, механика следующая:
Клиент логинится через браузер по OAuth 2.1 с PKCE и получает от Keycloak токен, выписанный специально для MCP-сервера. Дальше клиент просто прикрепляет его ко всем своим запросам.
Получив запрос, MCP-сервер берёт этот токен, стучится в Keycloak и меняет его (через token exchange по RFC 8693) на новый, предназначенный уже для конкретной целевой системы. Идентификатор пользователя при этом сохраняется. С этим новым токеном MCP-сервер и идёт в систему, действуя от лица юзера.
Но схема работает, только если конечная система умеет валидировать токены Keycloak. Например, с Jira DC это не прокатило - там пришлось поднимать отдельный OAuth-флоу до самой Джиры и хранить токены индивидуально для каждого пользователя в шифрованном кэше.
Чтобы не положить Keycloak постоянными запросами на обмен, новые токены кэшируются в памяти MCP-сервера. Они лежат там до тех пор, пока до истечения срока их действия (exp) не останется 30 секунд.
Token-exchange в клоке: мой MCP-сервер умеет в OAuth - при подключении авторизуемся через PKCE (через браузер), потом MCP-сервер меняет токен на соответствующий для таргета. Как я понимаю - вам больше первая стадия интересна
сравнивал мельком внутри - разница есть и она в пользу классического
bridge(rootful-сценарий), но с другой стороны во всех трёх случаях получал не менее 400Мбит на виртуальных машинах (Proxmox) в тестах с OpenSpeedTestВам понравится, думаю 😁 вот буквально ночью зарелизил https://github.com/andrico21/awg-rootless
Соглашусь с комментарием. Да, с
podmanиз коробки значительно проще организовать rootless-сценарии, но в статье виден только некий каркас без наполнения. Где реальные кейсы побега? (да, их действительно хватает - в статье лишь упоминание таковых без подробностей). Автор, расскажи про то какpastaотличается отslirp4netnsв части заголовков в пакетах, какие ограничения уpastaесть в плане работы сlocalhost.2gotch: rootless-мод в докере мало общего имеет с реализацией в подмане - демон всё-равно болтается :)