По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложения. Настало время более детально рассмотреть HTTP и REST.
Понимание HTTP имеет решающее значение для веб-разработчиков, поскольку оно облегчает поток информации в веб-приложении, позволяя улучшить взаимодействие с пользователями и повысить производительность сайта.
Что такое HTTP?
В клиент-серверной модели клиенты и серверы обмениваются сообщениями по принципу «запрос-ответ»: клиент отправляет запрос, а сервер возвращает ответ.
Хранить трек из этих сообщений сложнее, чем звучит, поэтому клиент и сервер придерживаются общего языка и набора правил. Этот «язык», или протокол, называется HTTP.
Протокол HTTP определяет синтаксис (формат и кодировку данных), семантику (значение, связанное с синтаксисом) и тайминг (скорость и последовательность). Каждый HTTP-запрос и ответ, которыми обмениваются клиент и сервер, рассматривается как одна HTTP-транзакция.
HTTP: Общая информация
Есть несколько вещей, которые стоит отметить про HTTP, прежде чем погрузиться в детали.
Во-первых, HTTP текстовый протокол, что означает, что сообщения, которыми обмениваются клиент и сервер, являются битами текста. Каждое сообщение содержит две части: заголовок и тело.
Во-вторых, HTTP - это протокол прикладного уровня, то есть это просто абстракционный уровень, который стандартизирует взаимодействие хостов. Сам HTTP не передает данные. Получение запроса и ответа от одной машины к другой по-прежнему зависит от базового протокола TCP/IP.
Напоминаем, что TCP/IP - это двухкомпонентная система, которая функционирует как фундаментальная «система управления» Интернета.
Наконец, возможно, вы видели протокол «HTTPS» в адресной строке браузера и интересовались, является ли HTTP тем же самым, что HTTP + «S». Если коротко, то HTTPS разновидность HTTP, с небольшой разницей.
Простой HTTP-запрос или ответ не зашифрован и уязвим для различных типов атак. HTTPS, напротив, является более безопасной протоколом связи, которая использует TLS/SSL шифрование для обеспечения безопасности.
SSL - это протокол безопасности, который позволяет клиенту и серверу взаимодействовать по сети безопасным способом - чтобы предотвратить сниффинг и подмену во время передачи сообщений по сети.
Клиент обычно указывает, требуется ли ему подключение TLS/SSL, используя специальный номер порта 443. Как только клиент и сервер соглашаются использовать TLS/SSL для обмена данными, они согласовывают соединение с отслеживанием состояния, выполняя так называемое «квитирование TLS». Затем клиент и сервер устанавливают секретные сеансовые ключи, которые они могут использовать для шифрования и дешифрования сообщений, когда они разговаривают друг с другом.
Многие крупные веб-сайты, такие как Google и Facebook, используют HTTPS - в конце концов, это то, что сохраняет ваши пароли, личную информацию и данные кредитных карт в безопасности.
Что такое API
HTTP: Углубляясь в детали
Теперь, вооружившись базовыми знаниями, погрузимся глубже в структуру HTTP.
Мы можем начать с посещения https://www.github.com, чтобы связаться с сервером GitHub. Если вы используете Chrome или Firefox с установленным расширением Firebug, вы можете подробно изучить HTTP-запрос, перейдя на вкладку «Сеть» или «Network». С открытой кладкой «Сеть», перейдите на сайт www.github.com, введя его в адресную строку, и вы должны увидеть что-то подобное:
Затем на левой панели щелкните по первому пути, «github.com.» Теперь вы должны увидеть следующее:
Заголовок запроса HTTP
Заголовки HTTP обычно содержат метаданные (данные о данных). Метаданные включают тип запроса (GET, POST, PUT или DELETE), путь, код состояния, тип содержимого, используемый браузер, cookie, текст сообщения (иногда) и многое другое.
Рассмотрим наиболее важные части заголовка на примере GitHub, начиная с раздела «Заголовки ответа»:
Request URL: https://github.com/ - Запрошенный URL-адрес
Request Method: GET - Тип используемого метода HTTP. В нашем случае наш браузер сказал: «Эй, сервер GitHub, я хочу ПОЛУЧИТЬ (GET) домашнюю страницу».
Status Code:200 OK - Стандартизированный способ информирования клиента о результате запроса. Код состояния 200 означает, что сервер успешно нашел ресурс и отправляет его вам.
Remote Address:192.30.252.129:443 - IP-адрес и номер порта веб-сайта GitHub, который мы посетили. Обратите внимание, что это порт номер 443 (это означает, что мы используем HTTPS вместо HTTP).
Content-Encoding: gzip - Кодировка ресурса, который мы получили обратно. В нашем случае сервер GitHub сообщает нам, что содержимое, которое он отправляет назад, сжато. Возможно, Github сжимает файлы, чтобы страница быстрее загружалась.
Content-Type: text/HTML; charset = utf-8 - Задает представление данных в теле ответа, включая тип и подтип. Тип описывает тип данных, в то время как подтип указывает конкретный формат для этого типа данных. В нашем случае, мы имеем текст, в формате HTML. Во второй части указывается кодировка символов для HTML-документа. Чаще всего это будет UTF-8, как и выше.
Есть также куча информации заголовка, которую клиент должен был отправить, чтобы сервер мог знать, как ответить. Посмотрите на раздел «Заголовки запросов» или «Headers»:
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 - Программное обеспечение, которым пользуется пользователь. Иногда веб-сайт должен знать, с какого устройства он просматривается. Поэтому браузер отправляет эту последовательность User-Agent, которую сервер может использовать для определения того, что используется для доступа к веб-сайту
Accept-Encoding: gzip, deflate, sdch - Указывает кодировку содержимого, которую может обработать браузер. Мы видим, что указан gzip, и поэтому сервер Github смог отправить нам содержимое в формате gzip.
Accept-Language: en-US, en; q = 0.8 - Описывает язык, на котором должна отобразиться веб-страница. В нашем случае «en» означает английский.
Host: github.com - Описывает хост, на который мы идем
Cookie:_octo=GH1.1.491617779.1446477115; logged_in=yes; dotcom_user=iam-peekay; _gh_sess=somethingFakesomething FakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFake; user_session=FakesomethingFake somethingFakesomethingFakesomethingFake; _ga=9389479283749823749; tz = America% 2FLos_Angeles _ - Фрагмент текста, который веб-сервер может хранить на компьютере пользователя и впоследствии извлекать. Информация сохраняется как пара имя-значение. Например, одна из пар имя-значение, сохраненных GitHub для моего запроса, является «dotcom_user=iam-peekay,», которая сообщает GitHub, что мой userid – Iam-peekay.
Что теперь со всеми этими парами имя-значение?
Итак, у нас есть много пар имя-значение. Но как создаются эти пары имя-значение?
Каждый раз, когда браузер будет открывать веб-сайт, он будет искать на компьютере файл cookie, установленный веб-сайтом ранее.
Так что, при посещении www.github.com, браузер будет искать файл cookie, который GitHub сохранил на жестком диске компьютера пользователя. Если он найдет файл cookie, он отправит все пары имя-значение в заголовке запроса.
Веб-сервер GitHub теперь может использовать данные cookie различными способами, такими как рендеринг контента на основе сохраненных пользовательских предпочтений, подсчет количества времени, проведённого на сайте.
Если браузер не находит файл cookie - либо потому, что сайт никогда не посещался, либо пользователь заблокировал или удалил его - браузер не отправляет данные cookie.
В этом случае сервер GitHub создает новый идентификатор в качестве пары имя-значение, вместе с любыми другими необходимыми ему парами имя-значение, и отправляет его пользователю через заголовок HTTP. Получив данные, устройство хранит их на своем жестком диске.
Тело HTTP
Выше мы узнали, что сервер содержит большинство важных «метаданных» (данные о данных), которые необходимы для связи с клиентом.
Теперь поговорим о теле HTTP запроса.
Тело – это основная часть сообщения. В зависимости от типа запроса он может быть и пустым.
В нашем случае вы можете увидеть тело на вкладке «Response». Поскольку мы сделали запрос GET на www.github.com, тело содержит содержимое HTML-страницы для www.github.com.
Дополнительные упражнения
Надеюсь, такой разбор позволит вам лучше понять структуру HTTP. На практике вы можете просмотреть на другие ресурсы, запрашиваемые вашим браузером (изображения, файлы JavaScript и т.д.) при посещении www.github.com.
Теперь рассмотрим различные методы HTTP запросов, которые клиент может инициировать.
Методы HTTP
Команды или методы HTTP указывают серверу, что делать с данными, определенными по URL. URL-адреса всегда идентифицируют определенный ресурс. Когда клиент использует URL-адрес в сочетании с командой HTTP, это сообщает серверу, какое действие необходимо выполнить с указанным ресурсом.
Примеры URL-адресов:
GET http://www.example.com/users (получить всех пользователей)
POST http://www.example.com/users/a-unique-id (создание нового пользователя)
PUT http://www.example.com/comments/a-unique-id (обновить комментарий)
DELETE http://www.example.com/comments/a-unique-id (удалить комментарий)
Когда клиент делает запрос, он указывает тип запроса, используя одну из этих команд. Наиболее важными являются GET, POST, PUT и DELETE. Есть и другие методы, такие как HEAD и OPTIONS, но они используются редко, поэтому в данном материале мы пропустим их.
GET
GET является наиболее часто используемым методом. Он используется для чтения информации по данному URL-адресу с сервера.
Запросы GET доступны только для чтения, что означает, что данные никогда не должны быть изменены на сервере - сервер должен просто извлечь данные без изменений. Таким образом, запросы GET считаются безопасными операциями, поскольку сколько бы не вызывай его, ответ будет одинаковым.
Кроме того, запросы GET являются идемпотентными. Это означает, что отправка нескольких запросов GET на один и тот же URL-адрес должна привести к тому же эффекту, что и один запрос GET, поскольку запрос GET просто запрашивает данные с сервера, а не изменяет их.
Запросы GET отвечают кодом состояния 200 (ОК), если ресурс был успешно найден, и 404 (NOT FOUND), если ресурс не был найден. (Отсюда термин «404 page» для сообщений об ошибках при посещении несуществующих или неправильно набранных URL-адресов.)
POST
POST используется для создания нового ресурса, например, через форму регистрации. Функция POST используется при необходимости создания дочернего ресурса (например, нового пользователя) для какого-либо родительского ресурса (http://example.com/users). Родительский ресурс запроса на создание новой сущности определяется по URL-адресу, и сервер обрабатывает новый ресурс и связывает его с родительским ресурсом.
POST не является ни безопасным, ни идемпотентным. Это связано с тем, что выполнение двух или более идентичных запросов POST приведет к созданию двух новых идентичных ресурсов.
Запросы POST отвечают кодом состояния 201 (CREATED) вместе с заголовком местоположения со ссылкой на вновь созданный ресурс.
PUT
PUT используется для обновления ресурса, идентифицированного по URL, с использованием информации в теле запроса. PUT также может использоваться для создания нового ресурса. Запросы PUT не считаются безопасными операциями, поскольку они изменяют данные на сервере. Однако он является идемпотентным, поскольку несколько идентичных запросов PUT на обновление ресурса должны иметь тот же эффект, что и первый.
Запросы PUT отвечают кодом состояния 200 (OK), если ресурс был успешно обновлен, и 404 (NOT FOUND), если ресурс не был найден.
DELETE
DELETE используется для удаления ресурса, определенного по URL-адресу. Запросы DELETE являются идемпотентным, поскольку если УДАЛИТЬ ресурс, он будет удален, и даже если вы сделаете несколько идентичных запросов DELETE, результат будет одинаковым: удаленный ресурс.
Скорее всего, вы просто получите сообщение об ошибке 404, если отправить запрос DELETE для одного и того же ресурса несколько раз, поскольку сервер не сможет найти его после удаления.
Запросы DELETE отвечают кодом состояния 200 (OK) в случае успешного удаления или 404 (NOT FOUND), если не удалось найти удаляемый ресурс.
Все вышеуказанные запросы возвращают значение 500 (ВНУТРЕННЯЯ ОШИБКА СЕРВЕРА), если обработка завершается неуспешно и сервер выдаёт ошибку.
Что же такое REST?
Перейдем к последнему термину – REST.
Возможно, вы слышали термин RESTful application ранее. Важно понимать, что это означает, потому что, если вы используете HTTP для обмена данными между клиентом и сервером, полезно следовать рекомендациям REST. На самом деле, HTTP-методы, которые мы рассмотрели выше, не что иное, как часть REST.
REST расшифровывается как Representational State Transfer (Передача состояния представления). Это архитектурный стиль проектирования приложения.
Основная идея заключается в том, что для выполнения вызовов между машинами используется протокол «без состояния», «клиент-сервер», «кэшируемый» - и чаще всего этот протокол HTTP. В общем, REST это согласованный набор ограничений для проектирования приложения. Эти ограничения помогают сделать систему более производительной, масштабируемой, простой, изменяемой, видимой, портативной и надежной.
Полный список ограничений очень длинный, и вы можете прочитать об этом здесь. В этой статье остановимся на двух наиболее важных из них:
1. Унифицированный интерфейс - Uniform interface: это ограничение позволяет определить интерфейс между клиентом и сервером путь, чтобы упростить и разъединить архитектуру. Там написано, что:
Ресурсы должны быть идентифицируемыми в запросе (например, с помощью идентификаторов ресурсов в URI). Ресурс (например, данные в базе данных) - это данные, которые определяют представление ресурса (например, JSON, HTML). Ресурсы и представления ресурсов - это концептуально разные сущности - клиент взаимодействует только с представлением ресурсов.
Клиент должен иметь достаточно информации для управления ресурсами на сервере с помощью представления ресурса.
Каждое сообщение, которым обмениваются клиент и сервер, должно быть самоописательным и содержать информацию о том, как обрабатывать сообщение.
Клиенты должны отправлять данные о состоянии с использованием основного содержимого HTTP, заголовка HTTP-запроса, параметров запроса и URL-адреса. Серверы должны отправлять данные о состоянии с помощью тела HTTP, кодов ответов и заголовков ответов.
Примечание: Описанные выше команды HTTP составляют основную часть ограничения «унифицированного интерфейса», поскольку они представляют собой единообразные действия, которые происходят с ресурсами.
2. Отсутствие состояния - Stateless: это ограничение говорит о том, что все данные о состоянии, необходимые для обработки запроса клиента, должны содержаться в самом запросе (URL, параметры запроса, тело HTTP или заголовки HTTP), а сервер должен отправить все необходимые данные о состоянии клиенту через сам ответ (заголовки HTTP, код состояния и тело ответа HTTP).
Примечание: Состояние - или состояние приложения - это данные, необходимые серверу для выполнения запроса.
Это означает, что для каждого запроса мы пересылаем информацию о состоянии туда и обратно, так что сервер не должен поддерживать, обновлять и отправлять состояние.
Наличие системы без сохранения состояния делает приложения намного более масштабируемыми, потому что ни один сервер не должен беспокоиться о поддержании одного и того же состояния сеанса на протяжении нескольких запросов. Все необходимое для получения данных о состоянии доступно в самом запросе и ответе.
Заключение
HTTP далеко не прост. Но, как вы видите, это критически важный компонент отношений между клиентом и сервером.
Для создания RESTful приложений требуется по крайней мере базовое понимание HTTP. С таким багажом знаний, следующий проект для вас будет намного проще.
Привет, дорогой читатель! Если ты когда-нибудь задавался вопросом – как перенести файл с хостовой машины на виртуальную в Hyper-V, то эта статья для тебя! Дело в том, что не всегда представляется возможным организовать сетевую связность между хостом и виртуальной машиной, а иногда это и вовсе не нужно. К счастью, в Hyper-V предусмотрена простая возможность переноса файлов прямо на виртуальные машины (как Windows так и Linux и другие) с помощью PowerShell и сейчас мы про неё расскажем.
Важно отметить, что данная функционал стал доступен только в 3 версии PowerShell. Поэтому проверьте установленную у себя версию. Для этого в консоли PowerShell введите команду $PSVersionTable
Процесс
Итак, сразу раскроем все карты. Для переноса файлов на гостевые (виртуальные) машины нужно использовать команду со следующим синтаксисом:
Copy-VMFile -Name “Имя виртуальной машины” -SourcePath ?Путь кфайлукоторыйхотим перенести? -DestinationPath ?Путь кпапке на виртуальной машинекуда хотимположить файл? -CreateFullPath -FileSource Host
Основой команды является часть Copy-VMFile, которая, в терминологии PowerShell, называется командлетом (Cmdlet) далее следуют ключи командлета, определяющие параметры и правила выполнения команды. Например, в примере выше, c помощью ключа -Name мы указываем имя виртуальной машины, на которую хотим скопировать файл, путь к которому указываем в ключе -SoucePath. Директория, в которую мы хотим поместить файл на виртуальной машине указывается в ключе -DestinationPath. Ключ -CreateFullPath создаст директорию, если её ещё нет. Ну и -FileSource Host означает, что источником, с которого мы переносим файл является хостовый сервер.
Однако, если вы выполните команду на текущем этапе без предварительной подготовки виртуальной машины, то получите следующую ошибку:
Чтобы этого избежать, необходимо предварительно включить в параметрах виртуальной машины поддержку гостевых сервисов (Guest Services). Для этого зайдите в параметры виртуальной машины, далее выберите Сервисы Интеграции (Integration Services) и поставьте галочку напротив Гостевые сервисы (Guest Services).
Или просто введите команду Enable-VMIntegrationService -Name ?Guest Service Interface? -VMName “Имя виртуальной машины”
После этого следует ввести команду Copy-VMFiles ещё раз, после чего начнётся копирование файлов с хоста в указанную директорию на виртуальной машине. Данный способ подходит для файлов любых размеров, ограничением является только используемое виртуальной машиной дисковое пространство.
Что такое SSO?
С помощью системы единого входа (SSO - single sign-on) клиенты могут получать доступ к различным сайтам и приложениям, используя всего один набор входных данных. SSO работает со стратегией подтверждения личности клиента. Это происходит, когда клиент входит в одну программу и сразу же получает доступ в других связанных приложениях. Различные имена пользователей и пароли теперь можно более эффективно отслеживать в различных учетных записях и ресурсах.
Удобно ведь, когда человек входит в Google, и его сертификаты за доли секунды подтверждаются в связанных ресурсах, включая Gmail и YouTube, без необходимости регистрации в каждой из них.
Токен SSO
Токеном системы единого входа (SSO Token) называется сбор информации или данных, которые отправляются с одной платформы на другую в процессе использования SSO. Это основополагающие данные такие, как адрес электронной почты клиента и сведения о системе, которая отправляет токен. Чтобы условный сборщик имел возможность подтвердить, что токен поступает из надежного источника, они должны быть строго промаркированы. В процессе настройки пересылается подтверждение надежности токена, используемого для этой маркировки.
Важность системы единого входа
SSO имеет важное значение в свете того факта, что постоянно растет количество ресурсов и учетных записей, доступ к которым клиентам необходимо контролировать, и каждый из этих ресурсов требует определенной степени безопасности, которая обычно обеспечивается с помощью комбинации имени пользователя и пароля. Тем не менее, руководителям и клиентам, которые стараются подобрать надежные пароли для нескольких учетных записей, может быть трудно упорядочить и работать с таким количеством учетных записей. Система единого входа поддерживает безопасный доступ к приложениям, унифицируя технику для руководителей и клиентов.
Процедура единого входа может выполняться с использованием различных методических инструкций, но все они соответствуют одной и то же базовой структуре. Важным аспектом является то, что они позволяют приложениям отдавать право подтверждения клиента другому приложению или администратору.
Этап SSO рассматривается как отдельное пространство, где можно работать лишь с идентификаторами клиентов.
Как работает SSO?
В основе лежат доверительные отношения между поставщиком услуг (Service Provider) – программой, и поставщиком удостоверений (Identity Provider) – например такой компанией, как OneLogin. Сертификат, которым обмениваются поставщик услуг и поставщик удостоверений, как правило, служит основой для этих самых доверительных отношений. Чтобы поставщик услуг знал, что идентификационная информация поступает из надежного источника, этот сертификат можно использовать для подписи этой идентификационной информации, которая передается от поставщика идентификационной информации поставщику услуг. В SSO эти идентификационные данные представляют собой токены, которые включают в себя идентифицирующие данные о человеке, такие как его адрес электронной почты или имя пользователя.
SSO работает на основе доверительных отношений, установленных между приложением, называемым поставщиком услуг, и поставщиком персональных данных, таким как OneLogin. Эти доверительные отношения часто основаны на положительном заключении, одобрении, которым обмениваются поставщик персональных данных и специализированная организация. Это одобрение можно использовать для подписи данных о пользователе, которые отправляются от поставщика персональных данных в специализированную организацию, чтобы поставщик услуг убедился в надежности источника данных. В SSO эта персональная информация отображается в виде токенов, которые содержат различимые фрагменты данных о клиенте, такие как адрес электронной почты клиента или имя пользователя.
Далее показано, как обычно происходит взаимодействие при входе в систему:
Клиент изучает программу или сайт – «поставщика услуг», к которому он хочет получить доступ.
Чтобы запросить проверку личности клиента у SSO, иначе называемой поставщиком удостоверений, поставщик услуг передает токен, который содержит некоторую информацию о клиенте, например, его адрес электронной почты.
Чтобы разрешить доступ к приложению поставщика услуг и сразу перейти к пункту 5, поставщик удостоверений должен для начала определить, проходил ли недавно клиент аналогичную проверку.
Если клиент этого еще не делал, ему будет предложено войти в систему, предоставив требуемые условия допуска поставщика удостоверений. Это может быть просто имя пользователя и пароль, или это может быть даже совсем другая стратегия подтверждения, например, одноразовый пароль.
Поставщик удостоверений отправляет обратно поставщику услуг символьные данные подтверждения фактической проверки каждый раз, когда он подтверждает отправленные сертификаты.
Программа клиента передает этот токен поставщику услуг.
Доверительные отношения, который были установлены между поставщиком услуг и поставщиком удостоверений во время основного соглашения, используются для утверждения пути проверки через символьные данные, полученные поставщиком услуг.
Специализированная организация (поставщик услуг) разрешает доступ клиента.
Новый сайт также должен иметь группу доверия, настроенную с механизмом SSO, и процесс проверки будет аналогичным, когда клиент попытается получить доступ к альтернативному сайту.
Типы конфигураций SSO
SAML - Открытый стандарт SAML (Security Access Markup Language) рассматривает обмен символьной информацией путем кодирования текста в машинный язык. На сегодняшний день SAML – один из основных принципов SSO, он помогает поставщикам приложений гарантировать правильность выполнения их требований проверки. Данные могут передаваться через интернет-браузер благодаря SAML 2.0, который был создан специально для использования в веб-приложениях.
OAuth - Компонент авторизации открытого стандарта, известный под названием oAuth, отправляет идентификационные данные между приложениями, используя шифрование машинного кода. Это особенно удобно для использования в локальных приложениях, поскольку позволяет клиентам разрешать доступ к своей информации, начиная с первого приложения, и далее в следующих приложениях, без необходимости подтверждать свою личность физически.
Kerberos - При неопределенной организации защиты клиент и сервер могут проверять личность друг друга, используя соглашение Kerberos. Клиенты и программирующие программы, такие как клиенты электронной почты или вики-серверы, проверяются с помощью пропускающего ресурса, который распространяет токены.
OIDC - OIDC расширяет OAuth 2.0 путем расширения возможности SSO и поддерживая явную информацию о клиенте. Это позволяет произвести однократную авторизацию для входа в систему для нескольких уникальных приложений. Например, позволяет клиентам входить в справочную систему, используя свою учетную запись Facebook или Google, а не вносить новую информацию в сертификат клиента.
Проверка подлинности смарт-карты - Помимо обычного SSO, существует также средства, поддерживающие подобный механизм. Модели устройств содержат устройства чтения карт, которые клиенты могут подключать к своим компьютерам. Для проверки личности клиента программа использует криптографические ключи, хранящиеся на карте. Карты должны находиться только у клиента во избежание утери. Их использование является дорогостоящим, независимо от того, являются ли они просто сами по себе безопасными или требуют PIN-код для работы.
Использование SAML и OAuth в SSO
Для проверки своей легитимности токены подтверждения используют рекомендации по обмену данными (переписке). SAML, который является языком для создания токенов подтверждения, является основной рекомендацией. XML используется в стандарте SAML для разрешения проверки личности клиента и передачи ему доступа, чтобы можно было связываться через зоны действия системы безопасности. SAML работает с перепиской между клиентом, SP и IdP при использовании его в SSO.
Данные клиентов должны безопасно предоставляться различным ресурсам с единственным входом в систему. Это становится возможным с OAuth, который позволяет различным внешним ресурсам использовать данные записи клиента. SP сообщает IdP о запросе клиента на доступ, который IdP затем проверяет и подтверждает, прежде чем предоставлять доступ клиенту. Решение зарегистрироваться на сайте, используя учебную запись Facebook, а не имя пользователя и пароль, является одним из примеров.
SSO может использоваться как для автономных соглашений OAuth, так и для SAML. В то время как SAML проверяет клиентов, OAuth используется для подтверждения доступа клиентов.
Преимущества и недостатки SSO
Преимущества:
Сокращение количества атак: SSO исключает возможность того, что закончатся пароли, а также правила подбора паролей, что делает организацию более защищенной от фишинга. Это исключает сбросы паролей, что является утомительным и дорогостоящим, и позволяет клиентам запоминать лишь один пароль.
Простой и безопасный клиентский доступ: SSO предоставляет организациям возможность оперативно получить информацию о том, какие клиенты, когда и откуда получили доступ к тем или иным приложениям, позволяя им тем самым защитить целостность своих инфраструктур. Механизмы SSO также могут справить с такими угрозами безопасности, как сбой рабочего устройства, позволяя IT-службам быстро блокировать доступ к учетным записям и важной информации на устройстве.
Улучшена оценка клиентского доступа. В постоянно меняющейся обстановке в организации, как правило, стараются обеспечить доступ законных сотрудников к базовым данным и активам на соответствующем уровне. В зависимости от работы, подразделения и статуса клиента права доступа могут быть реализованы с использованием механизмов SSO. Это обеспечивает различимость входных уровней.
Конкурентоспособность: пользователи отмечают более быстрый и удобный доступ к проектам, которые им необходимо завершить. Физическая обработка запросов – это задача, которая в основном раздражает клиентов. Проверка SSO избавляет от этой необходимости, предоставляя мгновенный доступ к огромному количеству приложений всего за одну галочку.
SSO – это наиболее важный этап защиты вашего бизнеса и его клиентов. Вы можете использовать SSO в качестве основы для других средств защиты, включая многофакторную проверку подлинности и сочетание проверки личности, оценки рисков и согласования советов директоров для выполнения предварительных требований и сокращения предоставления неверных данных. SSO делает вашу организацию легитимной и обеспечивает ее безопасность.
Недостатки:
SSO проста и практична в использовании, но если она не контролируется должным образом, то это может быть проблемой для безопасности. К проблемам SSO относятся:
Если злоумышленник получает права доступа SSO клиента, он также получает и доступ ко всем его приложениям. Соответственно, использование стратегий проверки, отличных от паролей, является основополагающим принципом.
Возможные недостатки: недавно злоумышленники получили несанкционированный доступ к веб-сайтам и различным записям из-за недостатков, обнаруженных к SAML и OAuth. Работа с поставщиком, который объединяет SSO с другими этапами проверки и управление личностями в своем продукте, является крайне необходимой в этом отношении.
Сходство приложений: иногда приложение может быть спроектировано так, что оно не очень подходит для работы с SSO. Будь то через SAML, Kerberos или OAuth, поставщики приложений должны обеспечить полноценную функциональность SSO. В любом другом случае, ваша система SSO не будет полностью вовлечена, а просто добавит еще один пароль, чтобы клиенты могли его восстановить.
Безопасна ли система SSO?
Однако неверно было бы утверждать, что SSO – это волшебное решение проблемы. Стоимость, контроль, нормализация (SAML против OAuth) и безопасность, безусловно, являются трудными задачами для организации системы единого входа. Сайт или ресурс могут быть подвержены атаке злоумышленника из-за проблем с проверкой, таких как уязвимость функции «Войти через Apple» или дефект Microsoft OAuth.
Кроме того, стоит понимать, что SSO-этап должен быть включен в более крупную корпоративную IT-структуру, поэтому следует тщательно продумать, как это сделать, сохраняя при этом общую безопасность. SSO, например, может помешать устройствам безопасности распознать начальный IP-адрес клиента при попытке пойти в вашу систему.
Несмотря на все это, использование SSO в большинстве случаев обеспечивает более высокий уровень безопасности, чем ожидание того, что клиенты будут контролировать все входы в систему для крупных бизнес-приложений. SSO явно сокращает количество моментов для атак, поскольку клиентам нужно реже регистрироваться и вспоминать меньше паролей. Директора могут более эффективно поддерживать меры предосторожности, такие как 2FA и надежные пароли, когда организация представляет собой единую структуру. Самое главное, что использование SSO, как правило, в любом случае безопаснее, чем его неиспользование.