Что такое неавторизованный доступ
Неавторизованный доступ к компьютерным сетям
Проблемы защиты информации в компьютерных сетях
Сформулируем 4 основных проблемы защиты информации в компьютерных сетях и системах удаленного доступа:
1. Идентификация и аутентификация пользователя — в системе должны иметься средства верификации того, что абонент на линии действительно является тем, за кого себя выдает.
2. Конфиденциальность обмена сообщениями — необходимо позаботиться о кодировании передаваемых данных.
3. Управление доступом к сети — прежде чем пользователь получит доступ к системе, необходимо установить его личность, поэтому система управления доступом должна представлять собой устройство, подключаемое к телефонной линии перед коммуникационным устройством.
4. Обнаружение несанкционированного доступа — если злоумышленник все-таки проник в сеть, необходимо иметь возможность определить, как был осуществлен доступ и какой урон понесет компания от несанкционированного входа.
Угрозы и уязвимые места
Неавторизованный доступ к компьютерным сетям
Неавторизованный доступ к компьютерным сетям (КС) имеет место, когда кто-то, не уполномоченный на использование КС, получает доступ к ней (действуя обычно, как законный пользователь КС).
Для получения неавторизованного доступа используется три общих метода: общие пароли, угадывание пароля и перехват пароля.
Общие пароли позволяют неавторизованному пользователю получить доступ к КС и привилегии законного пользователя; это делается с одобрения какого-либо законного пользователя, под чьим именем осуществляется доступ.
Угадывание пароля является традиционным способом неавторизованного доступа, когда пароль подбирается либо полным или словарным перебором, либо на основе знаний о легальном пользователе, чей пароль подбирается.
Неавторизованный доступ к КС может происходить с использованием следующих типов уязвимых мест:
— отсутствие или недостаточность схемы идентификации и аутентификации,
— совместно используемые пароли,
— плохое управление паролями или легкие для угадывания пароли,
— использование известных системных брешей и уязвимых мест, которые не были исправлены,
— однопользовательские ПК, не имеющие парольной защиты во время загрузки,
— неполное использование механизмов блокировки ПК,
— хранимые в пакетных файлах на дисках ПК пароли доступа к КС,
— слабый физический контроль за сетевыми устройствами,
— отсутствие тайм-аута при установлении сеанса и регистрации неверных попыток,
— отсутствие отключения терминала при многочисленных неудачных попытках установления сеанса и регистрации таких попыток,
— отсутствие сообщений “дата/время последнего удачного сеанса” и “неуспешная попытка установления сеанса” в начале сеанса,
— отсутствие верификации пользователя в реальном времени (для выявления маскарада).
неавторизованный доступ
Смотреть что такое «неавторизованный доступ» в других словарях:
несанкционированный доступ — Доступ к информации или к ресурсам автоматизированной информационной системы, осуществляемый с нарушением установленных прав и (или) правил доступа. Примечания 1. Несанкционированный доступ может быть осуществлен преднамеренно или непреднамеренно … Справочник технического переводчика
несанкционированная попытка доступа — неавторизованный доступ к компьютерным данным — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом Синонимы неавторизованный доступ к компьютерным данным EN… … Справочник технического переводчика
Система обнаружения вторжений — (СОВ) программное или аппаратное средство, предназначенное для выявления фактов неавторизованного доступа в компьютерную систему или сеть либо несанкционированного управления ими в основном через Интернет. Соответствующий английский… … Википедия
классификации угроз среде ИС — Неавторизованная модификация данных и программ происходящая в результате модификации, удаления или разрушения человеком данных и программного обеспечения ИС неавторизованным или случайным образом. Неавторизованный доступ к ИС происходящий в… … Справочник технического переводчика
Chrono Trigger — Обложка игры для Северной Америки (Super NES версия) Разработчики Square TOSE ( … Википедия
Персонажи Chrono Trigger — Chrono Trigger Обложка игры для Северной Америки (Super NES версия) Разработчик Square TOSE (DS) Издатели SNES Square … Википедия
Третья фаза: Неавторизованный доступ
Третья фаза: Неавторизованный доступ
Возвращаясь в свой офис, я размышляла над тем, как получить доступ к системам компьютерного зала. Оказавшись в офисе, я вошла в систему. Посмотрев на сетевую схему, я попыталась найти систему, в которой бы содержалась пикантная информация.
Иногда люди дают своим системам открытые имена (как в платежной ведомости), и по ним можно определить, какая информация в них хранится, даже не входя в них. Но не здесь. Все системы были обозначены буквенно-цифровой комбинацией (PR1, PR2 и т. д.). Никаких подсказок.
Я начала зондировать информацию систем наугад. Вы не знаете, как это делается? Я умела получать доступ в системы. Я достала из портфеля мою «походную» дискету и загрузила в систему несколько моих любимых инструментов. Инструменты облегчают нам жизнь. Набор хороших инструментов делает мир совершенно другим. В мой план входило попытаться войти в систему в качестве обычного пользователя, взломать корневой каталог и получить контроль над системой.
Я начала тестировать, доверяет ли мне какая-либо система компьютерного зала. В данном случае доверие означало, что системы были настроены доверять моей системе. Доверяемая система позволяет вам осуществлять легкий доступ без пароля. (Доверительные отношения в сетях могут быть опасными, так как если хакер взломает одну из систем, которой доверяют 50 других систем, то затем он сможет войти в эти 50 систем без пароля.) После того как скрипт был выполнен, оказалось, что мне доверяют десять систем. Не так плохо для меня. Но, определенно, плохо для больницы, для информации и для пациентов.
Я была в системе. Так как я имела учетную запись в машине, то мне представилась хорошая возможность получить информацию. Как только я вошла в первую машину (PR1), в мой офис зашла Мария. Я рассказала ей, что смогла без проблем пройти в компьютерный зал, но не сумела получить оттуда доступ к какой-либо информации. Она не поверила, что кто-нибудь смог бы зайти туда. Мне пришлось объяснять ей, почему я надела костюм.
Продолжая работать, я объяснила Марии мой способ входа в системы компьютерного зала. Я дала ей понять, что проведу остаток дня, собирая информацию. Я попросила ее организовать мне встречу с одним из системных администраторов и менеджером технической поддержки на следующий день. Она согласилась и довольная ушла от меня.
За небольшое время, около минуты, я получила полный контроль над системой. Если вы знакомы с приемами взлома, то это, возможно, покажется вам довольно долго. Как бы то ни было, десять систем, в которые я легко проникла, имели старую версию операционной системы. (Старые версии операционных систем могут сделать систему уязвимой, так как в них, скорее всего, остались старые программные ошибки, используемые хакерами для взлома.) Было похоже, что в этих системах выполнялись приложения, которые не были перенесены на новую версию операционной системы. По крайней мере, это была моя догадка.
Я запомнила эту мысль и начала искать доступ к остальным системам. За интересной работой время летит быстро. Я это поняла, когда было уже почти 5 часов дня. В любой момент за мной могла зайти Мария, чтобы проводить меня к выходу. Я приготовилась уйти. Результатом этого дня было получение доступа и полного контроля над 60 серверами. Кажется, системные администраторы Rockland установили их системы стандартным способом, без настройки безопасности или добавления патчей. Они также очень облегчили мне работу, установив доверительные отношения между значительным количеством серверов.
Как потенциального пациента, меня такая ситуация начинала пугать. Все критичные системы были доступны, и, насколько я видела, нигде не было контрольных журналов.[38] (Контрольный журнал фиксирует деятельность пользователей и ее характер). Опытный хакер мог хорошо позабавиться и уйти необнаруженным. В конце концов, мне удалось лично сегодня взломать 60 серверов, и ни в одном меня не заметили.
Мария появилась в 5.15. Всего я ей пока не рассказывала. Я дала ей понять, что смогла пробраться в некоторые системы и все еще собираю информацию. Бывает полезно придержать информацию о ходе аудита до его окончания. Я не люблю размениваться на мелочи, пока не соберу все факты.
Мария сообщила мне, что запланировала беседу на следующее утро. Я должна была встретиться с менеджером технической поддержки Мэттом Борландом и системным администратором Джилл Розенберг. Так как Мария была пунктуальна в составлении графика, то я решила закончить тестирование после проведения интервью сотрудников.
Читайте также
ЧАСТЬ ТРЕТЬЯ Примеры приложений
ЧАСТЬ ТРЕТЬЯ Примеры приложений Чтобы построить теорию, необходимо как следует знать основные феномены изучаемой области. Что касается теории вычислений, то мы не знаем этого предмета настолько, чтобы изложить его на высоком уровне абстракции. Напротив, нам следует
4. Третья нормальная форма (3NF)
4. Третья нормальная форма (3NF) Следующей нормальной формой, которую мы подвергнем рассмотрению, является третья нормальная форма (или 3NF). В отличие от первой нормальной формы, так же как и вторая нормальная форма, третья – подразумевает задание вместе с отношением системы
Фаза, событие и последовательность
Фаза, событие и последовательность Триггер может выполняться в одной из двух фаз, связанных с запрошенными изменениями состояния данных: до (before) записи или после (after) нее. Он может применяться к одному из трех событий DML: добавление, изменение или удаление. Начиная с Firebird
Проблема третья – неоднозначность
Проблема третья – неоднозначность Графологи не могут сойтись на определенном наборе признаков почерка. Каждый графолог или каждая школа, так или иначе, формирует свой набор. Интерпретируют они признаки тоже отчасти по-разному. Разные мнения и направления существуют во
Часть Третья
Часть Третья Сегодня у нас такое множество программ, что придется скомкать увертюрное культур-повидло до неприличного шматка эмоций. С ужасом обнаружил в Рунете сайт «По-русски о Ричарде Бахе»: «Мы, Дмитрий и Наталья Голубицкие, по мере наших возможностей будем знакомить
День 1-й: Неавторизованный доступ
День 1-й: Неавторизованный доступ Дэйв обнаружил хакера в системе в 11. 45 ночи в понедельник, во время плановой проверки сети. Он заметил, что выполняются необычные процессы и загруженность ценфальпого процессора значительно выше нормальной загруженности для этого
Год спустя: Неавторизованный доступ продолжается
Год спустя: Неавторизованный доступ продолжается В течение следующего года произошло несколько успешных взломов интранет ISD (успешных для хакера, разумеется). Единственной положительной стороной в них было то, что Чарльз получил сообщения о взломах от руководителя
Первая фаза: Физическая безопасность
Первая фаза: Физическая безопасность Чтобы начать игру, я должна была надеть костюм и исполнить свою роль. Моей целью было проникнуть в компьютерный зал без получения официального разрешения. Надев костюм, я попала в точку — я выглядела как своя.Мария предложила мне
Вторая фаза: Прохождение через систему физического контроля
Вторая фаза: Прохождение через систему физического контроля Я попросила Марию побыть в моем офисе и ждать моего звонка, если меня не пропустят. Легко было видеть, что мой подход ей понравился. (Ей самой, наверное, хотелось пойти со мной и посмотреть, что будет. Но она
Spectral Phase (фаза-частотный)
Spectral Phase (фаза-частотный) Spectral Phase дисплей показывает разность фаз в градусах, между левым и правым каналами. Например, если на какой-либо частоте отклонение в 180° по фазе, Spectral Phase дисплей показывает яркое пятно в положении +/- 180° градусов. Чем ярче цвет, тем громче данная
Глава третья
Глава третья Получив положительный ответ, за ужином я объявил о принятом решении. Мы с Костей шустро собрались и отправились в Кемерово. Дорога не близкая: сначала пешком, после на лошадях до охотничьего домика, где нас ждал «Патриот». В охотничьем домике было пусто,
АНАЛИЗЫ: Третья Азия
Обзор способов и протоколов аутентификации в веб-приложениях
Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.
Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.
Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.
Однако в современных системах существуют и более сложные схемы аутентификации и авторизации, о которых я расскажу далее. Но начнем с простого и понятного.
Аутентификация по паролю
Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.
Применительно к веб-приложениям, существует несколько стандартных протоколов для аутентификации по паролю, которые мы рассмотрим ниже.
HTTP authentication
Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:
Весь процесс стандартизирован и хорошо поддерживается всеми браузерами и веб-серверами. Существует несколько схем аутентификации, отличающихся по уровню безопасности:
Forms authentication
Для этого протокола нет определенного стандарта, поэтому все его реализации специфичны для конкретных систем, а точнее, для модулей аутентификации фреймворков разработки.
Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.
Пример forms authentication.
Приложение может создать session token двумя способами:
Другие протоколы аутентификации по паролю
Два протокола, описанных выше, успешно используются для аутентификации пользователей на веб-сайтах. Но при разработке клиент-серверных приложений с использованием веб-сервисов (например, iOS или Android), наряду с HTTP аутентификацией, часто применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях запроса.
Существует всего несколько мест, где можно передать username и password в HTTP запросах:
Распространенные уязвимости и ошибки реализации
Аутентификации по паролю считается не очень надежным способом, так как пароль часто можно подобрать, а пользователи склонны использовать простые и одинаковые пароли в разных системах, либо записывать их на клочках бумаги. Если злоумышленник смог выяснить пароль, то пользователь зачастую об этом не узнает. Кроме того, разработчики приложений могут допустить ряд концептуальных ошибок, упрощающих взлом учетных записей.
Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:
Аутентификация по сертификатам
Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.
На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.
В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.
Использование сертификата для аутентификации.
Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:
Пример X.509 сертификата.
После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).
Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.
Аутентификация по одноразовым паролям
Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.
Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.
Существуют разные источники для создания одноразовых паролей. Наиболее популярные:
Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.
В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.
Аутентификация по ключам доступа
Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.
В большинстве случаев, сервер генерирует ключи доступа по запросу пользователей, которые далее сохраняют эти ключи в клиентских приложениях. При создании ключа также возможно ограничить срок действия и уровень доступа, который получит клиентское приложение при аутентификации с помощью этого ключа.
Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.
Пример применения аутентификации по ключу.
Использование ключей позволяет избежать передачи пароля пользователя сторонним приложениям (в примере выше пользователь сохранил в веб-приложении не свой пароль, а ключ доступа). Ключи обладают значительно большей энтропией по сравнению с паролями, поэтому их практически невозможно подобрать. Кроме того, если ключ был раскрыт, это не приводит к компрометации основной учетной записи пользователя — достаточно лишь аннулировать этот ключ и создать новый.
С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.
Пример аутентификации по ключу доступа, переданного в HTTP заголовке.
Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.
Аутентификация по токенам
Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.
Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:
Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.
Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.
Пример аутентификации «пассивного» клиента посредством перенаправления запросов.
Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.
Сам токен обычно представляет собой структуру данных, которая содержит информацию, кто сгенерировал токен, кто может быть получателем токена, срок действия, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.
При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:
В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.
Форматы токенов
Существует несколько распространенных форматов токенов для веб-приложений:
Пример SWT токена (после декодирования).
Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
Стандарт SAML
Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.
Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:
Кроме того, стандарт определяет формат обмена метаинформацией между участниками, которая включает список поддерживаемых ролей, протоколов, атрибутов, ключи шифрования и т. п.
Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:
В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):
После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).
Стандарты WS-Trust и WS-Federation
WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.
Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.
Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:
Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.
Стандарты OAuth и OpenID Connect
В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).
Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.
Чтобы лучше понять сам стандарт, рассмотрим пример веб-приложения, которое помогает пользователям планировать путешествия. Как часть функциональности оно умеет анализировать почту пользователей на наличие писем с подтверждениями бронирований и автоматически включать их в планируемый маршрут. Возникает вопрос, как это веб-приложение может безопасно получить доступ к почте пользователей, например, к Gmail?
> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.
Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:
Взаимодействие компонентов в стандарте OAuth.
Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:
Стандарт не определяет формат токена, который получает приложение: в сценариях, адресуемых стандартом, приложению нет необходимости анализировать токен, т. к. он лишь используется для получения доступа к ресурсам. Поэтому ни токен, ни грант сами по себе не могут быть использованы для аутентификации пользователя. Однако если приложению необходимо получить достоверную информацию о пользователе, существуют несколько способов это сделать:
Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.
Заключение
В этой статье мы рассмотрели различные методы аутентификации в веб-приложениях. Ниже — таблица, которая резюмирует описанные способы и протоколы: