Виртуализация реализуется на нескольких уровнях. И каждый уровень имеет своё применение.
Виртуализация на уровне ОС - для ЦОД-ов и для поддержки других архитектур (например, надо запустить windows приложение на linux серверах и т. д.).
Виртуализация в рамках одной ОС (известна как контейнеризация) - для запуска отдельных сервисов. Это ещё на OpenVMS на железках DEC VAX делали. Потом появились Solaris Zones, FreeBSD Jail, на linux-ах это развилось в LXC, Docker, OCI/runC/containerd. И даже на linux-ах ушли от vendor lockin-а (kubernetes уже давно может запускать всё через CRI-O, где нет никакого docker-а).
Виртуализация на уровне отдельного приложение - тут flatpak, snap, bubblewrap, Citrix XenApp, которые позволяют запустить десктопное приложение в изолированной песочнице.
Виртуализация на уровне одного приложения - когда изоляция выполняется в рамках одного приложения для различных модулей. Из ярких представителей - это java application servers (WebSphere, WebLogic, Wildfly и другие).
Скорее наоборот, судя по остальным статьям, автор не один десяток лет жил в экосистеме IBM, поэтому все рассматривает исключтельно в сфере "В IBM сделали всё хорошо, а все остальные ещё доросли". Отсюда статьи подобного рода.
Но вы же сами написали, цитирую: "Единственная причина почему их нет по первой ссылке - потому что она касается исключительно OAuth2, без OIDC-надстройки." Вот я и хочу узнать, что же такого добавляет OIDC-надстройка чего нет в OAuth2. Может быть я чего-то не знаю, вот поэтому интересуюсь.
OIDC использует подписанные JWT, и требования, накладываемые на ключи для подписи, полностью аналогичные требованиям к ключам в SAML. Тот факт, что SAML использует сертификаты вместо JWK-описаний принципиально ничего не меняет.
Внезапно, но OAuth2 тоже может использовать подписанные JWT (RFC 9068) как и OIDC, более того что OAuth2, что OIDC используют одно и то же описание JWK. Требования к JWK описаны в RFC 8725. Вопрос же был в том, какие новые требования к сертификатам в OIDC кроме тех, которых предъявляются к OAuth2?
Вот с этого и надо начинать, так как до сих полно коробок, которые разрабатывались в начале 2000-х, то по инерции в корпоративной среде любят SAML. Если работает, то зачем менять?
AD FS - это реализация SAML, причём не единственная, из того, что одна реализация спецификации использует LDAP, не следует, что и вся спецификация SAML2.0 использует LDAP. Кроме того AD FS умеет в OIDC, мы же не будем говорить, что OIDC работает с LDAP?
Когда начинаем работать с SAML, то проблемы начинаются ещё до начала работы с SAML, в частности, надо корректно работать с входящими XML (отключить external entity и пр.), чтобы избежать XXE и других уязвимостей. У json-а подобных проблем нет.
Ну, некоторое упрощение чувствуется, но не сильное. От REST API тут одно название, спецификации что там, что там мозголомные.
Не одно название. Отлаживать OIDC/OAuth2 действительно проще, достаточно иметь консоль и curl. И json на 10 строк более читаем чем xml от SAML-а.
Что-то не видел я никакой принципиальной разницы в простоте настройки.
И в целом у OAuth2.0 всё более-менее сведено в одно место (отправная точка RFC 9700) и не надо бегать в поисках специалиста с сакральным знанием, как надо настраивать его.
Правильно ли я понимаю, что вся разница - в том, что SAML шлёт токен методом POST, в то время как OIDC использует GET, умещая всё что нужно в строку запроса? И у SPA с нативными приложениями сложности именно с получением тела запроса?
Речь про то, что в OIDC/OAuth2 есть разделение на пользователя и клиент, где клиентом может быть SPA, нативное приложение и любое другое. И для каждого клиента есть возможность управлять политиками и правилами. Например, каждому клиенту выдавать только свой набор ролей (у одного клиента запрашивать только логин/пароль, а для другого логин/пароль+второй фактор). Не говоря уже о ACR и LoA.
Кроме того, OAuth2 предлагает три варианта передачи токена:
параметр в GET-запросе - не желателен к использованию
параметр в Header - чаще всего используется
часть содержимого POST-запроса - реже используется.
Например, следующая ситуация, есть мобильное приложение, есть десктопное приложение, если веб-приложение. Используя эти разные клиенты, предоставляем доступ к одному и тому же ресурсу. При этом мы хотим при использовании десктопного приложения дать больше прав (например, десктопное приложение ставится только на доверенные ноуты в домене, есть поддержка цифровой подписи), а мобильному приложению хотим дать меньше прав (что-то сложное сделать нельзя, но получить статус, прочитать уведомление, прочитать краткое резюме). В OAuth2 это решается через клиенты, ACR, и у нас из коробки сразу же есть защита от mixup атак (это когда перехватили токен от мобилки, закинули в десктопное приложение и пытаемся получить расширенные права).
Как сделать разделение по правам между мобилкой и десктопным приложением в SAML2.0?
Автор ещё не указал, что OpenID Connect 1.0/OAuth 2.0 предоставляют возможности, которые отсутствуют в SAML2.0, например, управление сессией, чтобы клиент мог отслеживать сессию, мог обновить сессию, корректно завершить сессию (back-channel logout, front-channel logout, rp-initiated logout).
Так как Oracle использует undo-log для восстановления состояния, а undo-log ограничен, то на длительных транзакциях в Oracle можно словить в любой момент ошибку snapshot too old, когда Oracle не смог восстановить состояние из-за того, что в undo-log старые операции были просто затёрты.
Если вы не можете использовать IDM, то значит где-то храните и управляете данными помимо IDM, помимо конфликтов (данные пользователя изменили в IDM и там, откуда вы их тянете) возникает проблема, а зачем IDM, если он не выполняет фукнции IDM?
И Redis вы используете только для хранения отозванных токенов, оставляя проверку на ресурс серверы. Вместо того, чтобы завести IdP (Identity Provider), который будет хранить ключи для подписи, выписывать токены, проводить аутентификацию (а не авторизацию), проверять токены.
Для разделения на обычные и элитные эндпоинты давно существует ACR (Authentication Context Class), который как раз позволяет разделить токены (не эндпоинты!) на различные классы. И в запросе на элитный эндпоинт надо ещё прислать токен с соответствующим ACR.
Также советую посмотреть на RFC 9396 и RFC 9470, в которых описан процесс обогащения запросов на авторизацию для принятия решения выдачи токена. В них описывается процесс, когда при обращении на ресурс сервер получаем в ответе необходимые ACR (например, для запроса на элитный эндпоинт нужен второй фактор и др.). И можем обогатить запрос на получение токена необходимыми данными, так как scope не всегда хватает (например, указываем сумму операции, и уже на сервере авторизации принимаем решение, если сумма до 10000 руб., то одни проверки, если до 1000000 руб., то другие, если запросили доступ к элитным эндпоинтам, то третьи и т. д.)
Почему у вас в названии и тексте статьи используется слово "аутентификация", но в самой статье речь идёт только про авторизацию, и ни слова про аутентификацию? И картинка про двухфакторную аутентификацию, но ни слова про двухфакторную аутентификацию?
Почему не рассматриваете вариант поднятия отдельного IDM, который отвечает за данные пользователя, чтобы каждый сервис не ходил в общую СУБД за данными пользователя в первом варианте?
Плюс посмотрите в сторону RFC 8693: Token Exchange, когда сервис получает от пользователя токен, далее обменивает его на сервере авторизации на новый токен, который выдаёт права уже сервису на выполнение нужных ему действий. И тут у нас будет проверка токена пользователя на сервере авторизации, и управление правами сервиса.
все токены проходят валидацию через Redis.
Это как? Redis проверяет подпись JWT, сходит в сервер авторизации, чтобы понять, что сессия не протухла?
Ответить, достаточно или нет, сможет только ваш отдел информационной безопасности, так как он несёт ответственность за данный момент.
Так как у вас удалённая аутентификация, то надо смотреть в сторону OpenID Connect, я бы посоветовал посмотреть на атрибут azp, в котором пишется client_id клиента, которому был выдан токен: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
В каком JWT-токене? Их два, один для авторизации (OAuth2), второй для удалённой аутентификации, который содержит данные для клиента (OpenID Connect). И что такое "примитивные проверки" в JWT-токене?
Авторизация - это про выдачу прав, а не показывать данные пользователя. То, про что вы спрашиваете - это удалённая аутентификация, и надо смотреть в сторону OpenID Connect (в котором авторизация как раз OAuth2). Вот как раз OpenID Connect (OIDC) вводит понятие id token - это строго JWT-токен (в OAuth2 токен не обязательно JWT, может быть opaque - просто случайная строка), который содержит данные о пользователе для клиента.
Camunda:
Использует BPMN.
Сделана в классической клиент-серверной модели, где клиенты дёргают несколько серверов, выполняющих бизнес-процессы.
Ориентирована больше на условно не-IT специалистов, можно bpmn посмотреть в UI, ручками накидать процесс. Хотя кто этим занимается?
Temporal:
Не использует BPMN (никакого xml).
Построена на базе event-sourcing и горизонтального масштабирования (worker-ы можно добавлять в неограниченных количествах)
Больше ориентирована на разработчиков (вот вам grpc api, вот вам исходники - развлекайтесь), тут в основе код, а не диаграмма bpmn.
Виртуализация реализуется на нескольких уровнях. И каждый уровень имеет своё применение.
Виртуализация на уровне ОС - для ЦОД-ов и для поддержки других архитектур (например, надо запустить windows приложение на linux серверах и т. д.).
Виртуализация в рамках одной ОС (известна как контейнеризация) - для запуска отдельных сервисов. Это ещё на OpenVMS на железках DEC VAX делали. Потом появились Solaris Zones, FreeBSD Jail, на linux-ах это развилось в LXC, Docker, OCI/runC/containerd. И даже на linux-ах ушли от vendor lockin-а (kubernetes уже давно может запускать всё через CRI-O, где нет никакого docker-а).
Виртуализация на уровне отдельного приложение - тут flatpak, snap, bubblewrap, Citrix XenApp, которые позволяют запустить десктопное приложение в изолированной песочнице.
Виртуализация на уровне одного приложения - когда изоляция выполняется в рамках одного приложения для различных модулей. Из ярких представителей - это java application servers (WebSphere, WebLogic, Wildfly и другие).
Скорее наоборот, судя по остальным статьям, автор не один десяток лет жил в экосистеме IBM, поэтому все рассматривает исключтельно в сфере "В IBM сделали всё хорошо, а все остальные ещё доросли". Отсюда статьи подобного рода.
Но вы же сами написали, цитирую: "Единственная причина почему их нет по первой ссылке - потому что она касается исключительно OAuth2, без OIDC-надстройки." Вот я и хочу узнать, что же такого добавляет OIDC-надстройка чего нет в OAuth2. Может быть я чего-то не знаю, вот поэтому интересуюсь.
Внезапно, но OAuth2 тоже может использовать подписанные JWT (RFC 9068) как и OIDC, более того что OAuth2, что OIDC используют одно и то же описание JWK. Требования к JWK описаны в RFC 8725. Вопрос же был в том, какие новые требования к сертификатам в OIDC кроме тех, которых предъявляются к OAuth2?
Сам себе и отвечу, ACR есть в SAML2.0
Вот с этого и надо начинать, так как до сих полно коробок, которые разрабатывались в начале 2000-х, то по инерции в корпоративной среде любят SAML. Если работает, то зачем менять?
AD FS - это реализация SAML, причём не единственная, из того, что одна реализация спецификации использует LDAP, не следует, что и вся спецификация SAML2.0 использует LDAP. Кроме того AD FS умеет в OIDC, мы же не будем говорить, что OIDC работает с LDAP?
И какие же требования к сертификатам в OIDC, кроме тех, которые предъявляются к OAuth2?
Authentication Context Class Reference
В WS-Federation нет аналога UMA2.
Можете подробнее раскрыть, что подразумевается под этой фразой?
Когда начинаем работать с SAML, то проблемы начинаются ещё до начала работы с SAML, в частности, надо корректно работать с входящими XML (отключить external entity и пр.), чтобы избежать XXE и других уязвимостей. У json-а подобных проблем нет.
Не одно название. Отлаживать OIDC/OAuth2 действительно проще, достаточно иметь консоль и curl. И json на 10 строк более читаем чем xml от SAML-а.
Можно сравнить список рекомендаций по настройке:
Для OAuth2.0 https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html
Для SAML2.0 https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
И в целом у OAuth2.0 всё более-менее сведено в одно место (отправная точка RFC 9700) и не надо бегать в поисках специалиста с сакральным знанием, как надо настраивать его.
Речь про то, что в OIDC/OAuth2 есть разделение на пользователя и клиент, где клиентом может быть SPA, нативное приложение и любое другое. И для каждого клиента есть возможность управлять политиками и правилами. Например, каждому клиенту выдавать только свой набор ролей (у одного клиента запрашивать только логин/пароль, а для другого логин/пароль+второй фактор). Не говоря уже о ACR и LoA.
Кроме того, OAuth2 предлагает три варианта передачи токена:
параметр в GET-запросе - не желателен к использованию
параметр в Header - чаще всего используется
часть содержимого POST-запроса - реже используется.
Например, следующая ситуация, есть мобильное приложение, есть десктопное приложение, если веб-приложение. Используя эти разные клиенты, предоставляем доступ к одному и тому же ресурсу. При этом мы хотим при использовании десктопного приложения дать больше прав (например, десктопное приложение ставится только на доверенные ноуты в домене, есть поддержка цифровой подписи), а мобильному приложению хотим дать меньше прав (что-то сложное сделать нельзя, но получить статус, прочитать уведомление, прочитать краткое резюме). В OAuth2 это решается через клиенты, ACR, и у нас из коробки сразу же есть защита от mixup атак (это когда перехватили токен от мобилки, закинули в десктопное приложение и пытаемся получить расширенные права).
Как сделать разделение по правам между мобилкой и десктопным приложением в SAML2.0?
Автор ещё не указал, что OpenID Connect 1.0/OAuth 2.0 предоставляют возможности, которые отсутствуют в SAML2.0, например, управление сессией, чтобы клиент мог отслеживать сессию, мог обновить сессию, корректно завершить сессию (back-channel logout, front-channel logout, rp-initiated logout).
Или например динамическая регистрация клиента. Или аналог OAuth2 UMA2 (https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html).
Так как Oracle использует undo-log для восстановления состояния, а undo-log ограничен, то на длительных транзакциях в Oracle можно словить в любой момент ошибку snapshot too old, когда Oracle не смог восстановить состояние из-за того, что в undo-log старые операции были просто затёрты.
В рамках одной сессии может быть несколько refresh_token и access_token-ов.
Если вы не можете использовать IDM, то значит где-то храните и управляете данными помимо IDM, помимо конфликтов (данные пользователя изменили в IDM и там, откуда вы их тянете) возникает проблема, а зачем IDM, если он не выполняет фукнции IDM?
И Redis вы используете только для хранения отозванных токенов, оставляя проверку на ресурс серверы. Вместо того, чтобы завести IdP (Identity Provider), который будет хранить ключи для подписи, выписывать токены, проводить аутентификацию (а не авторизацию), проверять токены.
Для разделения на обычные и элитные эндпоинты давно существует ACR (Authentication Context Class), который как раз позволяет разделить токены (не эндпоинты!) на различные классы. И в запросе на элитный эндпоинт надо ещё прислать токен с соответствующим ACR.
Также советую посмотреть на RFC 9396 и RFC 9470, в которых описан процесс обогащения запросов на авторизацию для принятия решения выдачи токена. В них описывается процесс, когда при обращении на ресурс сервер получаем в ответе необходимые ACR (например, для запроса на элитный эндпоинт нужен второй фактор и др.). И можем обогатить запрос на получение токена необходимыми данными, так как scope не всегда хватает (например, указываем сумму операции, и уже на сервере авторизации принимаем решение, если сумма до 10000 руб., то одни проверки, если до 1000000 руб., то другие, если запросили доступ к элитным эндпоинтам, то третьи и т. д.)
Почему у вас в названии и тексте статьи используется слово "аутентификация", но в самой статье речь идёт только про авторизацию, и ни слова про аутентификацию? И картинка про двухфакторную аутентификацию, но ни слова про двухфакторную аутентификацию?
Почему не рассматриваете вариант поднятия отдельного IDM, который отвечает за данные пользователя, чтобы каждый сервис не ходил в общую СУБД за данными пользователя в первом варианте?
Плюс посмотрите в сторону RFC 8693: Token Exchange, когда сервис получает от пользователя токен, далее обменивает его на сервере авторизации на новый токен, который выдаёт права уже сервису на выполнение нужных ему действий. И тут у нас будет проверка токена пользователя на сервере авторизации, и управление правами сервиса.
Это как? Redis проверяет подпись JWT, сходит в сервер авторизации, чтобы понять, что сессия не протухла?
Ответить, достаточно или нет, сможет только ваш отдел информационной безопасности, так как он несёт ответственность за данный момент.
Так как у вас удалённая аутентификация, то надо смотреть в сторону OpenID Connect, я бы посоветовал посмотреть на атрибут
azp, в котором пишется client_id клиента, которому был выдан токен: https://openid.net/specs/openid-connect-core-1_0.html#IDTokenP.S.: есть ещё
aud, но у него другая семантика.В каком JWT-токене? Их два, один для авторизации (OAuth2), второй для удалённой аутентификации, который содержит данные для клиента (OpenID Connect). И что такое "примитивные проверки" в JWT-токене?
Авторизация - это про выдачу прав, а не показывать данные пользователя. То, про что вы спрашиваете - это удалённая аутентификация, и надо смотреть в сторону OpenID Connect (в котором авторизация как раз OAuth2). Вот как раз OpenID Connect (OIDC) вводит понятие id token - это строго JWT-токен (в OAuth2 токен не обязательно JWT, может быть opaque - просто случайная строка), который содержит данные о пользователе для клиента.
Ждём статью как купить квартиру без помощи риелторов.
Ужас, что кто-то в 2025 году до сих пор лицензируется по CPU.