emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Коллеги, хочу обратить внимание на приложение https://github.com/johannesjo/super-productivity/ в качестве цифрового персонального ежедневника (если кому удобней цифровые). 1. Open Source 2. Работает и на Android (доступен в т.ч. на F-Droid), и на iPhone…
Вдруг кому пригодится. На главной странице сайта org-mode https://orgmode.org/ перечислены решения, с помощью которых можно использовать org-mode на мобильных устройствах:
Android : Orgzly Revived, Orgro, Org Note
iOS : MobileOrg, Orgro
Web : Organice (progressive web app), Org Note
Android : Orgzly Revived, Orgro, Org Note
iOS : MobileOrg, Orgro
Web : Organice (progressive web app), Org Note
orgmode.org
Org Mode
Org: an Emacs Mode for Notes, Planning, Authoring and more!
❤4👍2🙏1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Pattern Specification можно реализовать парой строчек кода, в случае использования JSONB поля для хранения агрегата, путем применения jsonpath. Для реализации метода IsSatisfiedBy подойдет, например, - https://jsonpath2.readthedocs.io/en/latest/ А для компиляции…
С какими трудностями я обычно сталкивался в своей практике при реализации Specification Pattern?
1. Расслоение, если мы хотим применять его как для фильтрации объектов в оперативной памяти, так и в БД. Обычно эта проблема решается через Expression Tree, но в Golang такой опции нет, что, правда, легко обходится самодельным синтаксическим деревом.
При этом возникает вопрос о том, должна ли логика предиката реализовываться в виде интерпретатора на основе Expression Tree или дублироваться хардкодно?
2. Когда агрегаты храняться в JSONB колонке БД, обычно проблем не возникает, и мы можем применить коробочные реализации JSONPath.
Трудности возникают когда сущности агрегата хранятся в отдельных табличках без использования JSONB.
В частности, структура таблиц и структура агрегата нередко отличаются. Например, агрегат часто использует композитные первичные ключи и композитные ValueObjects. Это означает, что синтаксическое дерево для предиката агрегата будет отличаться от синтаксического дерева для запроса в БД. Т.е. просто так "коробку" прикрутить не получится. И мне известны только единичные специалисты, обладающие достаточной квалификацией, чтобы написать код трансформации одного дерева в другое.
3. Большинство коробочных интерпретаторов для Expression Tree, которые можно приспособить для реализации Specification Pattern, умеют оперировать только примитивными типами данных, и без существенной доработки не умеют совершать операции над ValueObjects, особенно, если язык программирования не поддерживает перегрузку операторов.
4. Инкапсуляция агрегата. Это отдельный большой вопрос, который часто обсуждается в отрасли и уже не раз обсуждался мной. Чаще всего для извлечения защищенного состояния агрегата используются:
1. Общие области видимости (как в Golang) или дружественные классы (C++).
2. Mediator Pattern (описан в красной книге Vaughn Vernon).
3. Рефлексия (нередко используется в коробочных решениях, особенно в ORM).
4. Memento Pattern, хотя и часто называют, но ошибочно, если внимательно разобраться.
5. Самая любимая моя проблема - это предикаты к атрибутам коллекции сущностей агрегата с использованием Expression Tree.
Как выразить в Expression Tree следующее условие:
хотя бы одна из сущностей коллекции агрегата имеет значение "x" атрибута "a" и значение "y" атрибута "b", или хотя бы одна из сущностей той же коллекции имеет значение "j" атрибута "с"?
Ничего не получится, если напишем нечто подобное:
Кажется, такое ни одна коробка не умеет, за исключением операторов wildcard "*" и локального елемента "@" в JSONPath. Собственно, оттуда я и перенял решение:
Если скомпилировать это выражение в SQL запрос к обычным реляционным табличкам (без JSONB), то получится два JOIN.
Не знаю, можно ли выразить нечто подобное с помощью LINQ в C# (если да, то сообщите, пожалуйста, в комментарии).
Когда должно вернуть true следующее выражение:
Когда совпадает хотя бы один элемент в обоих подмножествах, или когда оба подмножества эквиваленты?
Нет ничего сложного в реализации Specification Patrern on Expression Tree, если обладать достаточным опытом и квалификацией. Реализация занимает всего несколько сотен строк кода.
Сложно найти/подготовить такого специалиста в команду.
1. Расслоение, если мы хотим применять его как для фильтрации объектов в оперативной памяти, так и в БД. Обычно эта проблема решается через Expression Tree, но в Golang такой опции нет, что, правда, легко обходится самодельным синтаксическим деревом.
При этом возникает вопрос о том, должна ли логика предиката реализовываться в виде интерпретатора на основе Expression Tree или дублироваться хардкодно?
2. Когда агрегаты храняться в JSONB колонке БД, обычно проблем не возникает, и мы можем применить коробочные реализации JSONPath.
Трудности возникают когда сущности агрегата хранятся в отдельных табличках без использования JSONB.
В частности, структура таблиц и структура агрегата нередко отличаются. Например, агрегат часто использует композитные первичные ключи и композитные ValueObjects. Это означает, что синтаксическое дерево для предиката агрегата будет отличаться от синтаксического дерева для запроса в БД. Т.е. просто так "коробку" прикрутить не получится. И мне известны только единичные специалисты, обладающие достаточной квалификацией, чтобы написать код трансформации одного дерева в другое.
3. Большинство коробочных интерпретаторов для Expression Tree, которые можно приспособить для реализации Specification Pattern, умеют оперировать только примитивными типами данных, и без существенной доработки не умеют совершать операции над ValueObjects, особенно, если язык программирования не поддерживает перегрузку операторов.
4. Инкапсуляция агрегата. Это отдельный большой вопрос, который часто обсуждается в отрасли и уже не раз обсуждался мной. Чаще всего для извлечения защищенного состояния агрегата используются:
1. Общие области видимости (как в Golang) или дружественные классы (C++).
2. Mediator Pattern (описан в красной книге Vaughn Vernon).
3. Рефлексия (нередко используется в коробочных решениях, особенно в ORM).
4. Memento Pattern, хотя и часто называют, но ошибочно, если внимательно разобраться.
5. Самая любимая моя проблема - это предикаты к атрибутам коллекции сущностей агрегата с использованием Expression Tree.
Как выразить в Expression Tree следующее условие:
хотя бы одна из сущностей коллекции агрегата имеет значение "x" атрибута "a" и значение "y" атрибута "b", или хотя бы одна из сущностей той же коллекции имеет значение "j" атрибута "с"?
Ничего не получится, если напишем нечто подобное:
agg.ent[*].a == x && agg.ent[*].b == y && agg.ent[*].c == jКажется, такое ни одна коробка не умеет, за исключением операторов wildcard "*" и локального елемента "@" в JSONPath. Собственно, оттуда я и перенял решение:
agg.ent[*] ? (@.a == x && @.b == y) || agg.ent[*].c == jЕсли скомпилировать это выражение в SQL запрос к обычным реляционным табличкам (без JSONB), то получится два JOIN.
Не знаю, можно ли выразить нечто подобное с помощью LINQ в C# (если да, то сообщите, пожалуйста, в комментарии).
Когда должно вернуть true следующее выражение:
agg.ent1[*].a == agg.ent2[*].a ?Когда совпадает хотя бы один элемент в обоих подмножествах, или когда оба подмножества эквиваленты?
Нет ничего сложного в реализации Specification Patrern on Expression Tree, если обладать достаточным опытом и квалификацией. Реализация занимает всего несколько сотен строк кода.
Сложно найти/подготовить такого специалиста в команду.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Pattern Specification можно реализовать парой строчек кода, в случае использования JSONB поля для хранения агрегата, путем применения jsonpath.
Для реализации метода IsSatisfiedBy подойдет, например,
- https://jsonpath2.readthedocs.io/en/latest/
А для компиляции…
Для реализации метода IsSatisfiedBy подойдет, например,
- https://jsonpath2.readthedocs.io/en/latest/
А для компиляции…
👍8👏2❤1🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Архитектурное многостраничное руководство Microsoft по мультитенанту: - https://docs.microsoft.com/en-us/azure/architecture/guide/multitenant/overview Связанные ресурсы: - https://docs.microsoft.com/en-us/azure/architecture/guide/multitenant/related-resources
Performance testing and antipatterns for cloud applications:
- https://learn.microsoft.com/en-us/azure/architecture/antipatterns/
- https://learn.microsoft.com/en-us/azure/architecture/antipatterns/
Docs
Performance testing and antipatterns - Azure Architecture Center
Build scalability solutions for common stressors by learning about performance antipatterns. These are common practices that are likely to cause scalability problems when an application is under pressure.
👍5❤1🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Бомбовый инструмент управления проектами на простых текстовых файлах. Попробовал - остался в восторге. И уже начал использовать его. - https://github.com/taskjuggler/TaskJuggler Не хватает только работы со среднеквадратичным отклонением оценки (но этим вообще…
TaskJuggler может создавать множество версий плана, что позволяет его использовать для 3 point estimates technique PERT:
https://github.com/taskjuggler/TaskJuggler/issues/127
См. по слову "scenario":
https://taskjuggler.org/manual/Tutorial.html
Docs:
https://taskjuggler.org/tj3/manual/scenario.html
Я использую такой макрос:
В отчете можно указать какие сценарии выводить:
https://taskjuggler.org/tj3/manual/scenarios.html
Это работает, хотя и не совсем так, как должно работать по PERT estimation.
Как вариант, можно сделать кастомное поле для StandardDeviation:
https://taskjuggler.org/tj3/manual/extend.html
И вносить в него данные из PERT-калькулятора:
https://t.me/emacsway_log/1543
Для подсчета крайнего срока можно сделать csv-выгрузку и подсчитать в excel:
https://taskjuggler.org/tj3/manual/formats.html
Ну или добавить в страницу jQuery и подсчитать с помощью JavaScript:
https://taskjuggler.org/tj3/manual/rawhtmlhead.html
Потому что marco, к сожалению, математику не умеет делать.
Тем не менее, инструмент очень крутой, с высоким порогом вхождения. Наверное, лучшее из того, что я пробовал. Был разработан by Chris Schlaeger, Managing Director at Amazon Development Center Germany GmbH.
[UPDATE]: Как я уже говорил ранее, TaskJuggler можно интегрировать с различными системами управления задачами.
https://github.com/taskjuggler/TaskJuggler/issues/127
См. по слову "scenario":
https://taskjuggler.org/manual/Tutorial.html
Docs:
https://taskjuggler.org/tj3/manual/scenario.html
Я использую такой макрос:
macro pert [
optimistic:effort ${1}d
nominal:effort ${2}d
pessimistic:effort ${3}d
]
В отчете можно указать какие сценарии выводить:
https://taskjuggler.org/tj3/manual/scenarios.html
Это работает, хотя и не совсем так, как должно работать по PERT estimation.
Как вариант, можно сделать кастомное поле для StandardDeviation:
https://taskjuggler.org/tj3/manual/extend.html
И вносить в него данные из PERT-калькулятора:
https://t.me/emacsway_log/1543
Для подсчета крайнего срока можно сделать csv-выгрузку и подсчитать в excel:
https://taskjuggler.org/tj3/manual/formats.html
Ну или добавить в страницу jQuery и подсчитать с помощью JavaScript:
https://taskjuggler.org/tj3/manual/rawhtmlhead.html
Потому что marco, к сожалению, математику не умеет делать.
Тем не менее, инструмент очень крутой, с высоким порогом вхождения. Наверное, лучшее из того, что я пробовал. Был разработан by Chris Schlaeger, Managing Director at Amazon Development Center Germany GmbH.
[UPDATE]: Как я уже говорил ранее, TaskJuggler можно интегрировать с различными системами управления задачами.
GitHub
Make it possible to use the 3 point estimate technique · Issue #127 · taskjuggler/TaskJuggler
There seem to be no way to use 3 point estimates technique with tj3, it would be a nice new feature to have. http://en.wikipedia.org/wiki/Three-point_estimation
👍3❤1🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Это работает, хотя и не совсем так, как должно работать по PERT estimation.
В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное отклонение. Но TaskJuggrer в пессимистическом сценарии сложил оценки так, что они не пересекаются. Т.е. степень его пессимизма превышает расчетную. Это та причина, по которой лучше учитывать раздельно вероятностную оценку и её среднеквадратичное отклонение, как я описал во второй части предыдущего поста.
На одном из реальных проектов прямое сложение пессимистических оценок дало превышение вероятностного срока на полтора месяца, в то время как 3-sigma составил не более 9 дней. Так что здесь нужно с осторожностью.
Кстати, это та же самая причина, по которой Story Points можно сложить только на краткосрочном горизонте (спринт-два).
На одном из реальных проектов прямое сложение пессимистических оценок дало превышение вероятностного срока на полтора месяца, в то время как 3-sigma составил не более 9 дней. Так что здесь нужно с осторожностью.
Кстати, это та же самая причина, по которой Story Points можно сложить только на краткосрочном горизонте (спринт-два).
👍2❤1🔥1
- https://github.com/microsoft/ai-for-beginners
- https://github.com/microsoft/mcp-for-beginners
- https://github.com/microsoft/IoT-For-Beginners
Thanks to @vec650
- https://github.com/microsoft/mcp-for-beginners
- https://github.com/microsoft/IoT-For-Beginners
Thanks to @vec650
GitHub
GitHub - microsoft/AI-For-Beginners: 12 Weeks, 24 Lessons, AI for All!
12 Weeks, 24 Lessons, AI for All! Contribute to microsoft/AI-For-Beginners development by creating an account on GitHub.
👍10🔥5❤1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Вдруг кому пригодится. На главной странице сайта org-mode https://orgmode.org/ перечислены решения, с помощью которых можно использовать org-mode на мобильных устройствах: Android : Orgzly Revived, Orgro, Org Note iOS : MobileOrg, Orgro Web : Organice (progressive…
Увидел в Авито объявление: "сдам в аренду собаку, гадит где попало, обои рвет, мебель грызет, на всех бросается, идеальный вариант чтоб отбить желание у родственников обзавестись питомцем, дорого".
Это... я что подумал... есть на примете программист, очень умный (реально), гений, победитель олимпиад, в совершенстве знает алгортмы (легко пройдет собес в любой бигтех), ненавидит DDD (даже этот персонаж нервно покуривает в сторонке), в одиночку решает сложнейшие задачи, замыкает все задачи на себя (Рик и близко не валялся), руководствуется принципом "вы никогда не сможете понять ничего из того, что я создал", "ФП - херня", "абстракции - вредны", "сеттеры удобны", "ООП - оверинжиниринг", "анемичные модели понятны", "монолиты распределенными не бывают", "люди вообще писали на ассемблере и ничего, выжили"...
Готов заключить с ним агентское соглашение и сдавать его в аренду. Дорого. Если кому нужно укрепить переговорную позицию перед бизнесом - обращайтесь. На руках носить потом будут.
Это... я что подумал... есть на примете программист, очень умный (реально), гений, победитель олимпиад, в совершенстве знает алгортмы (легко пройдет собес в любой бигтех), ненавидит DDD (даже этот персонаж нервно покуривает в сторонке), в одиночку решает сложнейшие задачи, замыкает все задачи на себя (Рик и близко не валялся), руководствуется принципом "вы никогда не сможете понять ничего из того, что я создал", "ФП - херня", "абстракции - вредны", "сеттеры удобны", "ООП - оверинжиниринг", "анемичные модели понятны", "монолиты распределенными не бывают", "люди вообще писали на ассемблере и ничего, выжили"...
Готов заключить с ним агентское соглашение и сдавать его в аренду. Дорого. Если кому нужно укрепить переговорную позицию перед бизнесом - обращайтесь. На руках носить потом будут.
Хабр
Самый неадекватный кандидат за мою карьеру
Были кандидаты, которые после первого рабочего дня на радостях в запой уходили… Но вчера ребята провели первичный скрининг и наткнулись на одного из самых сложных кандидатов за последние годы. Сегодня...
😁16🔥2❤1🍾1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Как я делаю fitness-functions для микросервисов. Продолжение. Начало здесь. По хуку before_scenario() (или before_tag()) создается дамп изначального состояния БД (если он не был создан ранее) утилитой pg_dump в многопоточном режиме, с использованием аргументов:…
По сути дела, здесь речь идет о реализации fitness-functions (если сделать небольшие допущения):
- https://learn.microsoft.com/en-us/training/modules/run-non-functional-tests-azure-pipelines/
Информации на эту тему немного, поэтому подобные руководства имеют большую ценность.
См. также:
- https://learn.microsoft.com/en-us/azure/load-testing/overview-what-is-azure-load-testing
- https://t.me/emacsway_log/1506
- https://learn.microsoft.com/en-us/training/modules/run-non-functional-tests-azure-pipelines/
Информации на эту тему немного, поэтому подобные руководства имеют большую ценность.
См. также:
- https://learn.microsoft.com/en-us/azure/load-testing/overview-what-is-azure-load-testing
- https://t.me/emacsway_log/1506
Docs
Run nonfunctional tests in Azure Pipelines - Training
Run automated load tests by using Apache JMeter, a form of nonfunctional testing, in Azure Pipelines.
👍2🔥1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
Книга "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.
Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.
В посте традиционно для книги указал ссылку на Амазон, однако сразу хочу сказать, что в электронном виде книгу авторы сами раздают бесплатно (подсказка: данные в форме можно указать любые).
В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients
Собственно, их и намереваюсь рассмотреть, начав с первой.
#book #iam_general #oauth
Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.
Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.
В посте традиционно для книги указал ссылку на Амазон, однако сразу хочу сказать, что в электронном виде книгу авторы сами раздают бесплатно (подсказка: данные в форме можно указать любые).
В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients
Собственно, их и намереваюсь рассмотреть, начав с первой.
#book #iam_general #oauth
🔥2👍1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
Первая часть обзора книги "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
🔵 Как будто больше маркетинга, чем рациональных доводов
🔵 В доводах указываются вещи, которые я бы не связал напрямую с OAuth
🔵 Не хватило секции “почему не что-то другое”
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Илиюный неокрепший ум… Не знаю, в общем.
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
1️⃣ Identity & Access Management — Authorization Server
2️⃣ API Management — API Gateway
3️⃣ Entitlement Management — Policy Engine
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Или
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Cloud native is a technology approach for operating services and infrastructure in a vendor-neutral way.
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[1/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
👍1🔥1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[2/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
🔵 валидация входящих временных учетных данных
🔵 трансляция их в JWT access token для конечных сервисов.
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
🔵 Здесь получаете не отдельный токен доступа в виде JWT, а обернутый в JWT тот же ответ от introspection endpoint
🔵 Таким образом два представления токена доступа полноценно не “развязать”: полученный JWT не ограничить отдельно по времени жизни или области действия
🔵 Сами авторы RFC пишут, что возвращаемый здесь JWT “is not an alternative representation of the introspected access token and is not intended to be used as an access token”
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
🔵 Flexibility (API работают только с предоставленным результатом, саму логику контроля доступа можно изменять, не ломая их)
🔵 Auditability (имеем события аудита как для применения политик, так и их для изменения)
🔵 Security agility (отделение ЖЦ политик доступа от ЖЦ конечных сервисов)
🔵 Quality assurance via policy as code (если политики прописываются отдельно, сами сервисы могут не тестировать их внутреннюю логику, а покрывать только возможные исходы)
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
While secure flows are essential, they should be complemented by a keen focus on access tokens.
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
We have seen that your overall API security is distributed between the API gateway APIs, and possibly additional components such as service meshes.
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1🔥1
Forwarded from Архитектура ИТ-решений
Когда речь заходит о записях архитектурных решений (architecture decision records, ADR) часто возникает вопрос: где посмотреть реальный пример? Вот чтоб в проекте более-менее долго фиксировались решения, уточнялись, пересматривались и т.п.
... и тут все обычно начинают мяться, вспоминают про NDA
Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.
... и тут все обычно начинают мяться, вспоминают про NDA
Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.
GitHub
GitHub - nats-io/nats-architecture-and-design: Architecture and Design Docs
Architecture and Design Docs . Contribute to nats-io/nats-architecture-and-design development by creating an account on GitHub.
❤7👍2🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное…
Немного модифицировал JIRA to TaskJuggler convertor ( https://github.com/emacsway/jira-juggler ), чтобы он сохранял иерархию Epic -> UserStory -> Task. Удобно для извлечения и планирования эпика целиком.
GitHub
GitHub - emacsway/jira-juggler: JIRA to TaskJuggler convertor
JIRA to TaskJuggler convertor. Contribute to emacsway/jira-juggler development by creating an account on GitHub.
👍1🔥1🙏1
Forwarded from Системный сдвиг
Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
👍8🤔2❤1
Forwarded from SWE notes
Putting the “You” in CPU
Отличный материал для погружения в работу ПК на примере Linux.
Простым языком описано что такое прерывание, мультизадачность и прочие системные вещи
#sysprog #linux #os
Отличный материал для погружения в работу ПК на примере Linux.
Простым языком описано что такое прерывание, мультизадачность и прочие системные вещи
#sysprog #linux #os
Putting the "You" in CPU
Curious exactly what happens when you run a program on your computer? Learn how multiprocessing works, what system calls really are, how computers manage memory with hardware interrupts, and how Linux loads executables.
👍5🔥1
Catalog of legacy modernization patterns by Nick Tune:
https://legacy-modernization.io/patterns/
https://legacy-modernization.io/patterns/
Legacy-Modernization.io
Patterns
Common patterns for modernizing legacy systems.
🔥9
Forwarded from Russian Association of Software Architects (Ivan)
"On Orchestrators: You Are All Right, But You Are All Wrong Too"
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
Dlthub
On Orchestrators: You Are All Right, But You Are All Wrong Too
👍1
Forwarded from Russian Association of Software Architects (Сергей Баранов)
www.latent.space
The 2025 AI Engineering Reading List
We picked 50 paper/models/blogs across 10 fields in AI Eng: LLMs, Benchmarks, Prompting, RAG, Agents, CodeGen, Vision, Voice, Diffusion, Finetuning. If you're starting from scratch, start here.
👍3