Если злоумышленник скомпрометировал клиентскую машину, то ни Kerberos, ни OIDC, ни SAML2.0 не помогут, они не предусматривают защиту от подобного вида атак. Тем более наличие прав администратора. Можно залезть в кэш браузера пользователя и оттуда вытащить все токены.
TGT живёт очень долго, service ticket имеют сильно меньший срок жизни, есть возможность повесить 2FA на выдачу service ticket, чтобы пользователь во-первых видел, куда идёт доступ, а во-вторых имел возможность подтвердить или отклонить доступ.
В таком случае получим, что даже при компрометации TGT злоумышленник не сможет получить доступ к сервисам, пользователь будет видеть странные запросы на доступ, куда не заходит, и отклонять их.
приводит к ошибке на старте gradle: Cannot set the value of extension 'spotbugs' property 'reportLevel' of type com.github.spotbugs.snom.Confidence using an instance of type java.lang.Class
Ловим NPE в непредсказуемых местах из-за оператора !!, который любят ставить kotlin-разработчики. Или из-за библиотек на java, которые вернули внезапно null. А как вы выполняете проверку на null при переходе от nullable к nonnull?
Поддержка IDE?
И ооооооочень долгая компиляция kotlin-программы. В итоге переключение между ветками превращается в ад, когда успеваешь сходить заварить, чай, подождать когда он остынет, выпить, а компиляция ещё идёт. Именно поэтому так носятся с новым компилятором K2, одной из фич которой является более быстрая компиляция.
Виртуализация реализуется на нескольких уровнях. И каждый уровень имеет своё применение.
Виртуализация на уровне ОС - для ЦОД-ов и для поддержки других архитектур (например, надо запустить 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).
Если злоумышленник скомпрометировал клиентскую машину, то ни Kerberos, ни OIDC, ни SAML2.0 не помогут, они не предусматривают защиту от подобного вида атак. Тем более наличие прав администратора. Можно залезть в кэш браузера пользователя и оттуда вытащить все токены.
TGT живёт очень долго, service ticket имеют сильно меньший срок жизни, есть возможность повесить 2FA на выдачу service ticket, чтобы пользователь во-первых видел, куда идёт доступ, а во-вторых имел возможность подтвердить или отклонить доступ.
В таком случае получим, что даже при компрометации TGT злоумышленник не сможет получить доступ к сервисам, пользователь будет видеть странные запросы на доступ, куда не заходит, и отклонять их.
В Kotlin data-классы:
В Java record-классы:
Совместимость ломается в непредсказуемых местах. Пример: https://github.com/spotbugs/spotbugs-gradle-plugin/issues/972 - в плагине spotbugs есть два enum-а Effort и Confidence. Они лежат рядом, но после переписывания плагина на kotlin один enum недоступен, то есть вот такой конфиг:
приводит к ошибке на старте gradle:
Cannot set the value of extension 'spotbugs' property 'reportLevel' of type com.github.spotbugs.snom.Confidence using an instance of type java.lang.ClassПриходится изгаляться через костыли:
null-safety?
Ловим NPE в непредсказуемых местах из-за оператора
!!, который любят ставить kotlin-разработчики. Или из-за библиотек на java, которые вернули внезапно null. А как вы выполняете проверку на null при переходе от nullable к nonnull?Поддержка IDE?
И ооооооочень долгая компиляция kotlin-программы. В итоге переключение между ветками превращается в ад, когда успеваешь сходить заварить, чай, подождать когда он остынет, выпить, а компиляция ещё идёт. Именно поэтому так носятся с новым компилятором K2, одной из фич которой является более быстрая компиляция.
А на Хабре есть правило, чтобы перед публикацией статьи, автор должен прочитать минимум один раз то, что сгенерировала нейронка?
Уже очень давно сделали https://www.oversec.io/, который позволяет пересылать текст с шифрованием eye-to-eye.
Там своя закрытая лицензия https://gitriver.ru/license
Хабр утонул в низкокачественных нейрогаллюцинациях, которые авторы даже не читают перед публикацией.
Спасибо, это я знаю. Вопрос к автору статьи, зачем он предлагает в обучающем материале сделать Entity с помощью data-класса?
Расскажите, пожалуйста, почему не стоит Entity делать как data-классы?
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).