Кратко

  • RFC 4422 различает идентичность, связанную с учётными данными, и идентичность, от имени которой клиент просит действовать; сервер проверяет доказательство и право представительства отдельно.
  • Успешный обмен SASL может установить состояние сеанса или защитный слой, но не подменяет решения приложения о последующих операциях и ресурсах.

У слова «успех» должен оставаться предмет

Зелёная отметка удобна, пока понятно, что именно она подтверждает. Действительны ли учётные данные, разрешено ли одному субъекту представлять другого, готов ли сервер допустить сеанс и можно ли выполнить действие над конкретным объектом — это разные вопросы. Единая запись «вход успешен» стирает границы между ответами.

SASL располагается между прикладным протоколом с соединением и сменными механизмами аутентификации. Механизм описывает проверку учётных данных. Профиль протокола определяет перенос сообщений и то, как результат меняет прикладное состояние. Такое устройство позволяет обновлять одну часть, не переписывая другую.

После успешного обмена может включиться согласованный защитный слой. С сеансом может быть связана идентичность. Однако список разрешённых почтовых ящиков, команд, наборов данных или административных функций из этого не возникает. Немедленный отказ следующей операции может означать не сбой, а правильно сохранённую границу.

Две идентичности под одним именем на экране

RFC 4422 называет идентичностью аутентификации ту, что связана с учётными данными. Идентичность авторизации — это субъект, от имени которого клиент хочет действовать. При обычном входе значения совпадают, поэтому интерфейс показывает одно имя.

Пустая строка идентичности авторизации означает просьбу действовать как субъект, которого сервер связал с учётными данными. Но модель допускает представительство: A доказывает, что он A, и просит работать как B.

Сервер решает две задачи. Он проверяет доказательства A и устанавливает идентичность аутентификации. Затем он отдельно решает, вправе ли A действовать как B. Провал любой проверки завершает обмен неудачей. Правильный пароль не превращается в доверенность только потому, что клиент назвал чужую идентичность.

Даже принятый B не является глобальным комплектом разрешений. Это идентичность в состоянии авторизации данного протокола. Возможность читать ресурс, менять запись или превышать лимит всё ещё определяется правилами приложения.

Профиль приложения дописывает смысл

Ядро SASL не навязывает всем протоколам единую систему идентичности. Профиль обязан определить, как объявляются и выбираются механизмы, переносятся вызовы и ответы, представляется идентичность авторизации, начинается защитный слой и взаимодействуют несколько слоёв. Он также объясняет последствия повторной аутентификации.

Этот перечень распределяет ответственность. Механизм можно усилить, не обучая его семантике почтового ящика. Протокол может принять новый механизм, не меняя все прикладные команды. Но команды не должны предполагать, будто механизм принёс политику, которой в нём нет.

В работающей системе сетевое имя проходит нормализацию, сопоставление с внутренней учётной записью, группами и атрибутами, а затем попадает в правило ресурса. Безупречная трасса SASL не подтверждает актуальность и корректность этих локальных связей.

SMTP-код 235 отвечает только за AUTH

SMTP AUTH даёт точный пример. RFC 4954 определяет 235 2.7.0 Authentication Succeeded как успешный ответ на команду AUTH и связывает идентичность авторизации с SMTP-сеансом. Это не квитанция о результате будущей почтовой транзакции.

Если AUTH согласовал защитный слой, SMTP возвращается в начальное состояние. Клиент и сервер отбрасывают ранее полученные сведения о возможностях, после чего клиенту следует снова отправить EHLO. Успешная аутентификация может не завершить диалог, а начать заново его прикладную часть.

Политика ретрансляции, проверка адресатов, контентные ограничения, очередь и доставка остаются последующими решениями. Этот пример нужен не для повторения спора о приёме и доставке, а для более узкого вывода: даже однозначный код успеха относится к определённой команде.

SASL может успешно никого не установить

RFC 4505 описывает механизм ANONYMOUS, который позволяет получить обычно ограниченный доступ, не устанавливая и не раскрывая идентичность пользователя. Необязательная трассировочная строка не аутентифицируется и может быть подделана.

Поэтому сочетание SASL и успеха в журнале ещё не означает «проверенный пользователь». Аналитику нужно знать обещание выбранного механизма. Система, которая превращает анонимный сеанс в подтверждённую личность, сама создаёт доказательство, отсутствующее в стандарте.

Более сильное доказательство не исправляет права

RFC 7677 зарегистрировал SCRAM-SHA-256 и SCRAM-SHA-256-PLUS. SHA-256 и требования, связанные с привязкой канала, усиливают заменяемую часть аутентификации. Механизм при этом не узнаёт, кому принадлежит конкретный ресурс и кто вправе выполнить привилегированную команду.

Криптографическое обновление может снизить риск утечки учётных данных или путаницы каналов. Оно не удалит лишнего участника группы, просроченное представительство или неверное правило приложения. Проверка только нового механизма способна поставить современную аутентификацию перед старой ошибкой авторизации.

Журнал должен различать решения

Для расследования нужны отдельные поля: выбранный механизм, защита канала, идентичность из учётных данных, запрошенная и принятая идентичность авторизации, правило представительства и последующее решение над ресурсом. Единственное поле «пользователь» упрощает схему, но разрушает объяснимость.

Без разделения похищенные данные, слишком широкая делегация, устаревшее сопоставление каталога и чрезмерное право приложения выглядят одинаково. Бита успеха достаточно автомату состояний, но недостаточно для восстановления ответственности.

Интерфейс также может говорить точнее. «Выполнен вход как» описывает сеанс. «Разрешено изменить объект» утверждает результат проверки конкретного действия. Тогда отказ после входа воспринимается не как загадочная неисправность, а как собственный контроль сервиса.

Источники