tgoop.com/emacsway_log/1553
Last Update:
Первая часть обзора книги "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще 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