SAML Basics
SAML Огляд
Мова маркування безпеки (SAML) дозволяє використовувати постачальників ідентичності (IdP) для надсилання облікових даних авторизації постачальникам послуг (SP), що полегшує одноразовий вхід (SSO). Цей підхід спрощує управління кількома входами, дозволяючи використовувати один набір облікових даних на кількох веб-сайтах. Він використовує XML для стандартизованого зв'язку між IdP та SP, пов'язуючи аутентифікацію особи користувача з авторизацією послуг.
Порівняння між SAML та OAuth
SAML орієнтований на надання підприємствам більшого контролю над безпекою входу SSO.
OAuth розроблений для більшої зручності використання на мобільних пристроях, використовує JSON і є спільною ініціативою таких компаній, як Google та Twitter.
Потік аутентифікації SAML
Для отримання додаткової інформації перегляньте повну статтю за посиланням https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Це резюме:
Процес аутентифікації SAML включає кілька етапів, як показано на схемі:
Спроба доступу до ресурсу: Користувач намагається отримати доступ до захищеного ресурсу.
Генерація запиту SAML: SP не розпізнає користувача і генерує запит SAML.
Перенаправлення до IdP: Користувач перенаправляється до IdP, запит SAML проходить через браузер користувача.
IdP отримує запит: IdP отримує запит SAML.
Аутентифікація в IdP: IdP аутентифікує користувача.
Перевірка користувача: IdP перевіряє легітимність користувача для доступу до запитуваного ресурсу.
Створення відповіді SAML: IdP генерує відповідь SAML, що містить необхідні твердження.
Перенаправлення до URL ACS SP: Користувач перенаправляється до URL служби споживання тверджень (ACS) SP.
Перевірка відповіді SAML: ACS перевіряє відповідь SAML.
Доступ до ресурсу надано: Доступ до спочатку запитуваного ресурсу надано.
Приклад запиту SAML
Розгляньте сценарій, коли користувач запитує доступ до захищеного ресурсу за адресою https://shibdemo-sp1.test.edu/secure/. SP виявляє відсутність аутентифікації та генерує запит SAML:
Сирийний SAML запит виглядає так:
Ключові елементи цього запиту включають:
AssertionConsumerServiceURL: Вказує, куди IdP має надіслати SAML Response після аутентифікації.
Destination: Адреса IdP, куди надсилається запит.
ProtocolBinding: Визначає метод передачі повідомлень протоколу SAML.
saml:Issuer: Ідентифікує суб'єкт, який ініціював запит.
Після генерації SAML Request, SP відповідає з 302 перенаправленням, направляючи браузер до IdP з SAML Request, закодованим у заголовку Location HTTP-відповіді. Параметр RelayState підтримує інформацію про стан протягом транзакції, забезпечуючи, щоб SP розпізнав початковий запит ресурсу при отриманні SAML Response. Параметр SAMLRequest є стиснутою та закодованою версією сирцевого фрагмента XML, що використовує стиснення Deflate та кодування base64.
Приклад SAML Response
Ви можете знайти повний SAML response тут. Ключові компоненти відповіді включають:
ds:Signature: Цей розділ, XML Signature, забезпечує цілісність та автентичність видавця асерції. SAML response в прикладі містить два елементи
ds:Signature, один для повідомлення та інший для асерції.saml:Assertion: Ця частина містить інформацію про особу користувача та, можливо, інші атрибути.
saml:Subject: Вказує основний суб'єкт усіх заяв у асерції.
saml:StatusCode: Відображає статус операції у відповідь на відповідний запит.
saml:Conditions: Деталізує умови, такі як терміни дійсності асерції та вказаного постачальника послуг.
saml:AuthnStatement: Підтверджує, що IdP аутентифікував суб'єкта асерції.
saml:AttributeStatement: Містить атрибути, що описують суб'єкта асерції.
Після SAML Response процес включає 302 перенаправлення від IdP. Це призводить до POST-запиту до URL-адреси Assertion Consumer Service (ACS) постачальника послуг. POST-запит включає параметри RelayState та SAMLResponse. ACS відповідає за обробку та валідацію SAML Response.
Після отримання POST-запиту та валідації SAML Response, доступ надається до захищеного ресурсу, спочатку запитаного користувачем. Це ілюструється запитом GET до кінцевої точки /secure/ та відповіддю 200 OK, що вказує на успішний доступ до ресурсу.
XML Підписи
XML Підписи є універсальними, здатними підписувати ціле XML-дерево або конкретні елементи в ньому. Вони можуть бути застосовані до будь-якого XML-об'єкта, а не лише до елементів Response. Нижче наведені ключові типи XML Підписів:
Основна структура XML Підпису
XML Підпис складається з основних елементів, як показано:
Кожен Reference елемент позначає конкретний ресурс, що підписується, який можна ідентифікувати за атрибутом URI.
Типи XML підписів
Enveloped Signature: Цей тип підпису є нащадком ресурсу, який він підписує, що означає, що підпис міститься в тій же XML структурі, що й підписаний контент.
Приклад:
У enveloped signature елемент ds:Transform вказує, що він обгорнутий через алгоритм enveloped-signature.
Enveloping Signature: На відміну від enveloped signatures, enveloping signatures обгортають ресурс, що підписується.
Приклад:
Detached Signature: Цей тип відокремлений від контенту, який він підписує. Підпис і контент існують незалежно, але між ними підтримується зв'язок.
Приклад:
На завершення, XML підписи забезпечують гнучкі способи захисту XML документів, кожен тип відповідає різним структурним і безпековим потребам.
References
Last updated
