По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье мы разберем, как устанавливать операционную систему Ubuntu Linux.
Сразу сделаем оговорку, установка операционной системы на виртуальную машину или на реальный ПК/сервер ничем не отличается - разница заключается лишь в том, что может отличатся набор программного обеспечения эмулирующих работу системы виртуализации. И в данном контексте могут быть нюансы.
Мы будем использовать платформу виртуализации Virtual Box. Дистрибутив находится в публичном доступе по ссылке https://www.virtualbox.org. Тут переходим в раздел Downloads и выбираем нужный нам установщик. Мы будем устанавливать программу на Windows, поэтому для скачивания нажимаем Windows hosts.
Данный дистрибутив может скачать любой желающий и установить, он совершенно бесплатен. Установка его достаточно проста, заключается в нажатии кнопки “Next” несколько раз. Нет необходимости вносить изменения - нам подойдут параметры по умолчанию.
В процессе система поставит все необходимые компоненты, в том числе драйвер захвата пакетов и на некоторых моделях ПК/серверов/ноутбуков попросит перезагрузить компьютер. В результате успешной установки на рабочем столе мы увидим иконку запуска приложения Virtual Box.
Запускаем и можем начать создавать наш виртуальный сервер. Для установки операционной системы нам понадобится дистрибутив операционной системы. Данные дистрибутивы находятся в свободном доступе в интернете. С данного сайта https://ubuntu.com/ (или https://ubuntu.ru/ на русском языке) можно скачать дистрибутив Ubutnu или с данного сайта https://www.centos.org/ можно скачать дистрибутив CentOS.
Теперь можно начать создавать виртуальную машину. Нажимаем кнопку "Создать". Появляется диалоговое окно создания виртуальной машины. Необходимо ввести ее название, выбрать тип (в нашем случае Linux) и выбрать версию (в нашем случае Ubuntu x64). Выбор x64 разрядной операционной системы обусловлен фактором работы с оперативной памятью более 3 ГБ. В случае с x32 разрядной операционной системой вся память, что более 3 ГБ видна операционной системе видна не будет.
Нам нужно выделить ей некое количество оперативной памяти, память выделяется из пула доступной оперативной памяти материнской машины (например, если у нас ноутбук с 8 ГБ оперативной памяти, следовательно мы можем выделить от 0 до 6 ГБ, до 6 ГБ потому, что материнской операционной системе тоже требуется для функционирования оперативная память). В большинстве случаев достаточно 2 ГБ оперативной памяти. Далее выбираем папку, где будет хранится файл с настройками виртуальной машины и виртуальный жесткий диск. Система виртуализации создает файл жесткого диска, который занимает объем, который вы выделяете для работы виртуальной машине. Нажимаем кнопку “Создать”.
На следующем шаге система спрашивает, где будем хранить жесткий диск и его объем, тип и формат. Выбираем тип жесткого диска VDI (“Родной” для VirtualBox) и указываем размер HDD. Нажимаем еще раз кнопку “Создать”.
После этого появляется наша виртуальная машина в списке, и мы можем нажать кнопку "Запустить".
После этого система предлагает выбрать загрузочный диск. Нажимаем значок папки.
Получаем вот такое диалоговое окно c выбором дистрибутива загрузочного диска.
Если данное окошко пусто, то необходимо нажать кнопку "Добавить" и указать путь к скаченному файлу установки. Выбираем, затем нажимаем кнопку "Продолжить".
Виртуальная машина видит установочный дистрибутив начинает запускать установочную оболочку.
Если, вы планируете установку версии для Desktop – то можете выбрать удобный для вас язык, в случае установки в качестве серверной выбирать следует язык Английский, потому что это позволит избежать ошибок локализации, которые периодически присутствуют на любой операционной системе.
На следующем экране система попросит определить клавиатуру, можно нажать Identify keyboard для определения, но обычно оболочка корректно определяет тип клавиатуры и изменения не требуется.
Следующий шаг - сетевые настройки.
Тут ситуация следующая - можно оставить по умолчанию IP адрес, который был выдан системой виртуализации, а можно сделать, самостоятельную настройку сети и даже создать интерфейс агрегации для увеличения пропускной способности сервера, но это уже продвинутый уровень, пока нам хватит текущих параметров.
Следующий экран предлагает ввести адрес proxy–server для доступа в интернет, данная опция необходима если в корпоративной среде используется такой сервер.
Следующий шаг - установка просит указать альтернативный источник файлов в сети интернет. Затем - разметка разделов жесткого диска, также можно оставить по умолчанию. При нажатии "Далее" появляется сводная таблица по изменениям, которые будут сделаны на жестком диске.
Можно увидеть, что система достаточно гибко позволяет разметить жесткий диск и файловую систему.
После нажатия "Далее", появляется вот такое окошко с подтверждением. Оно появляется вследствие того, что все файлы на данном разделе будут уничтожены. Следовательно, чтобы подтвердить необходимо выбрать "Continue".
После этого происходит, новая разметка жесткого диска. Разметка — это разделение общего пространства диска на логические разделы. Мы разбили доступное пространство на логические разделы.
Далее необходимо заполнить поля - имя пользователя, имя серверарабочей станции, пароль.
Нажимаем "Далее". Следующий экран предлагает нам установить OpenSSH сервер - данный пакет опционален, но лучше его поставить. OpenSSH нам позволит подключаться к серверу в дальнейшем по протоколу SSH.
И последний экран перед началом установки - оболочка спрашивает, какие пакеты могут понадобиться для работы. Можно пока пропустить.
После нажатия "Далее" начинается установка операционной системы.
При наличии интернета система, автоматически обращаться будет к своим репозиториям за обновлениями. Если мы хотим сократить время установки, то при появлении кнопки "Cancel update and reboot" мы можем отменить данное обновление и перезагрузить VM. Затем на экране появится ошибка, что операционная система не может размонтировать CD-ROM, нажимаем Enter и операционная система начинает грузится. Данное сообщение появляется, т.к. CD-ROM виртуальный и она это не понимает и не может его физически открыть. Следовательно, данное сообщение не имеет значения.
После перезагрузки, мы получаем полнофункциональную операционную систему.
Заходим под логином и паролем, которые мы указывали на этапе установки операционной системы.
Готово, успех! 🏆
Мы установили Linux на виртуальную машину.
В первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложения. Настало время более детально рассмотреть 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. С таким багажом знаний, следующий проект для вас будет намного проще.
Предприятия, использующие различные бизнес-приложения, должны поддерживать конфиденциальность данных и предоставлять права доступа в соответствии с ролями пользователей во всей инфраструктуре. Сделать это достаточно сложно. SAML (Security Assertion Markup Language) значительно помогает в этом плане.
Давайте посмотрим, что же это такое и как оно работает, в чем его преимущества, чем оно отличается от SSO, а в чем оно похоже, и как оно помогает в проверке доступа к API для обеспечения максимального уровня безопасности.
Что такое SAML?
Основная работа SAML заключается в том, чтобы позволить IdP (поставщикам удостоверений - identity details providers) делиться учетными данными, связанными с аутентификацией, с соответствующими органами. Это открытый стандарт, который позволяет предоставить унифицированный доступ для всех видов приложений без ущерба для безопасности данных.
Вот еще несколько фактов, которые вы должны знать о SAML:
Он использует XML для завершения стандартного соединения между IdP и поставщиками услуг для обеспечения надежной связи.
Процесс аутентификации SAML подтверждает личность конечного пользователя, а авторизация SAML определяет, какие ресурсы должны быть доступны для пользователя.
Он проверяет SP (поставщиков услуг), IdP (поставщиков удостоверений) и конечных пользователей, если пользователь имеет право на требуемое действие.
Это стандарт OASIS.
Обеспечивает безопасный обмен данными.
Он поддерживает активацию SSO. Однако данная процедура требует подключения к внешнему поставщику удостоверений и совместного с ним использования XML-токенов.
Кратко о SSO (Single Sign-on – система однократного входа)
SSO считается одним из самых эффективных механизмов аутентификации и объединяет несколько экранов входа. Это значит, что вам не нужно самостоятельно входить в систему в своих приложениях. Вместо этого для приложений SaaS (Software as a Service) будет работать всего один набор данных для входа для всех ваших учетных записей.
Это обеспечивает более быстрый доступ к приложению, делает его более простым и подконтрольным. Это является ключевым аспектом IAM-стратегий компаний, стремящихся к беспрепятственной проверке доступа к приложениям и наилучшей реализации безопасности.
Включение SSO дает следующие возможности:
Надежные пароли, так как нет необходимости создавать несколько схожих паролей. Достаточно иметь один сложный и надежный пароль.
Пользователям не нужно запоминать различные пароли.
Простое использование MFA (Многофакторная аутентификация), которое проверяет несколько факторов, так как его активация в одной точке обеспечивает защиту различных приложений.
Политика быстрого повторного ввода пароля, поскольку у администраторов есть единственная точка применения политики.
Удобное внутренне управление учетными данными, поскольку SSO хранит пароли пользователей внутри и предоставляет IT-специалистам гораздо больший контроль над базой данных.
Мгновенное восстановление пароля пользователя, поскольку IT-команда должна работать над восстановлением одного пароля.
Аутентификация SAML – пошагово
Давайте рассмотрим всю процедуру в нескольких шагах.
Прежде всего, служба идентификации передает входные данные, связанные со входом пользователя в систему, поставщику услуг. Для бесперебойной передачи параметров SAML поставщикам услуг каждый конечный пользователь обязан один раз войти в систему через SSO.
Затем, SP связывается с IdP для подтверждения достоверности запроса. Этот процесс также требует предоставления согласия на настройку системы однократного входа SAML. Это гарантирует то, что для проверки личности и авторизации пользователя/запроса используются одни и те же параметры SAML.
Преимущества SAML
Данный подход имеет стандартный формат, поэтому он предоставляет предприятиям открытый подход, не зависящий от совместимости платформ и реализаций поставщиков.
Он использует слабосвязанные каталоги, что означает, что нет необходимости хранить и синхронизировать пользовательские данные с локальными каталогами.
Так как он поддерживает SSO, то конечные пользователи получат доступ к приложениям.
SAML позволяет предприятиям повторно использовать интеграции для регистрации/входа, сохраняя при этом тот же уровень безопасности. Это значительно сокращает расходы на управление аккаунтом.
Обязанность обслуживания удостоверений пользователей переносится на IdP, когда работает SAML. Это освобождает поставщиков услуг от лишних проблем, связанных с регистрацией и входом в систему.
Что такое SAML Assertion?
Выражаясь простым языком, это документ в формате XML, который содержит в себе информацию о статусе авторизации пользователя. Эта информация предоставляется IdP поставщику услуг.
Есть утверждения трех типов:
Authentication – это проверка личности пользователя, связанных с ней методов и сведения об отслеживании продолжительности сеанса.
Assigned обеспечивает успешную передачу SAML-токенов поставщику услуг. IdP и SP используют одни и те же атрибуты для подтверждения личности создателя запроса.
И последнее, утверждение типа Authorization-decision объясняет, где пользователю предоставляется доступ в соответствии с его запросом. Если будет отказано в доступе, то также будет предоставлена подробно описанная причина этого отказа.
Пример SAML
Ниже приведен самый простой пример того, как SAML обрабатывает свои операции:
Пусть конечный пользователь по имени Джон пытается получить доступ к бизнес-приложению в служебных целях.
Джон начинает сеанс с SSO и завершает часть процедуры проверки личности.
Zoho CRM запрашивает у IdP информацию о пользователе для подтверждения.
Программное средство SaaS получает доступ к результатам для завершения этапа проверки полномочий.
IdP отвечает по этому запросу в формате SAML. На нем будут цифровые подписи Джона. На основании сходства между идентифицированными данными, которые предоставил Джон и IdP, в ответном сообщении могут содержаться и другие сведения.
Программное средство SaaS получает ответ и предоставляет доступ или отказывает в доступе в соответствии с инструкциями IdP.
Если доступ был разрешен, то Джон может использовать свою учетную запись Zoho.
SAML vs SSO
SAML помогает в проверке личности пользователя и делает возможным использование системы однократного входа (SSO). SSO может существовать отдельно и позволяет конечным пользователям использовать различные приложения с унифицированными данными для входа. SSO может задействовать стандартные протоколы SAML при обмене информацией, поскольку у него нет собственным специальных протоколов. Помимо этого, он может использовать сторонние протоколы, такие как OpenID, для эффективной междоменной проверки личности пользователя. SAML имеет же широкий спектр собственных протоколов.
SAML vs oAuth2
Из-за сходства основного назначения SAML 2.0 и oAuth 2.0 часто принимают за одно и то же программное средство. Хотя они и имеют некоторое сходство, но они также имеют и различия в некоторых аспектах.
Сходства
И то, и другое необходимо для обеспечения безопасного взаимодействия приложений.
Оба поддерживают простое управление доступом и быструю интеграцию.
Различия
oAuth 2.0 больше уделяет внимание на авторизацию, тогда как SAML отдает приоритет аутентификации.
SAML основан на XML, а oAuth 2.0 – на JSON.
SAML поддерживает данные сеанса с помощью файлов cookie, в то время как oAuth использует вызовы API.
Аутентификация API с помощью SAML
Несмотря на то, что одним из самых распространенных вариантов применения SAML является поддержка проверка личности пользователя и включение SSO, он также может оказаться полезным для проверки подлинности запроса в API. Проверка прав доступа пользователя для проверки подлинности запроса является ключевой с точки зрения безопасности API и может быть проведена путем отправки SAML-запроса, который в свою очередь должен предусматривать следующее:
SAML подготавливает запрос аутентификации API на основе API-интерфейса.
Запрос должен содержать SAML-сообщение, которое может поддерживать процесс SSO, автоматически инициируемый IdP.
Очень важно, чтобы сообщение SAML-запроса основывалось на закодированном XML-документе с корневым элементом <Response>.
Тело запроса должно содержать текстовое наполнение, идентификаторы и область. Первые два аспекта являются обязательными, третий – нет.
Ответ SAML включает в себя access_token (маркер SAML, предоставляющий или запрещающий доступ), username (имя пользователя), expires_in, refresh_token и realm (область).
Заключение
SAML и SSO тесно связаны друг с другом. Это критически важно для обеспечения безопасности данных без каких-либо компромиссов. Надеюсь, эта статья поможет вам разобраться в теме и больше узнать об этих двух программных средствах.