Архитекторы ничего не выдумывают. Они трансформируют реальность.

Алваро Сиза Виэйра

Много всего уже сказано и написано про фреймворк авторизации OAuth 2.0 с 2012 года. И, казалось бы, все давно его знают, используют, все должно работать надежно и безопасно.
Но, как обычно, на практике все иначе. В работе в реальности приходится сталкиваться с небезопасными реализациями процессов авторизации и аутентификации. Огорчает, что по статистике Россия занимает непочетное первое место по своей уязвимости.
Почему же так получается? Предлагаю вместе со мной и авторами драфта OAuth 2.1 от июля 2020 года сделать небольшую работу над ошибками. Это и будет отражением, на мой взгляд, того, по какому пути развития идет фреймворк OAuth 2.

Также спешу предупредить строгого читателя, что в данной статье я затрону только вопросы и сложности, связанные с реализациями по OAuth 2.0. Я не ставлю цели обозначить все проблемы с безопасностью в России в ИТ, и почему этот вопрос требует особого пристального внимания сегодня.

BIAN… как мало в этом звуке для сердца русского… Да, я не случайно перефразировала всем известного классика. В России популярность референтной модели BIAN все еще низкая, особенно в сравнении с моделью Enhanced Telecom Operations Map (eTOM), распространенной в опережающей по своему развитию телекоммуникационной отрасли. А между тем, модель BIAN развивается, совершенствуется и набирает популярность за пределами России и в международном сообществе банковской индустрии.

Не стану более отвлекать читателя на лирические отступления, скажу только, что обзор модели BIAN и сопроводительных документов стандарта есть в первой моей статье о BIAN, здесь же постараюсь рассказать, чем BIAN может быть полезен бизнес-менеджерам, бизнес-архитекторам, корпоративным архитекторам, архитекторам решений, ИТ-специалистам и всем другим лицам, интересующимся управлением всей архитектуры финансового предприятия. А также о его ключевых полезных трансформациях, на мой взгляд.

Архитектура: искусство делать излишнее необходимым.

Фредерик Кислер

Ни для кого давно уже не секрет, что для любого web-сервиса на протоколе SOAP с сообщениями в формате XML верным и проверенным временем решением является предварительная разработка XML Schema (xsd-схемы), описывающей типы данных и структуру XML сообщений. При этом подходе у разработчиков существует явное преимущество: у них есть строгие стандартизированные правила по структуре сообщений, которые заданы в схеме, число правил конечно, и они позволяют автоматизировать проверку любого нового сообщения в формате XML.