SAML v2.0 срещу JWT: SAML2 Web Application SSO случаи на използване

Тази публикация продължава нашия поглед върху SAML v2.0 и как се сравнява с JSON Web Tokens (JWT). В последния пост разгледахме историята, спецификациите и основите на SAML v2.0. В тази публикация започваме да проучваме подробно случаите на използване на SAML v2.0.

SAML2 в дивата природа

Средният потребител може да не осъзнае, че SAML2 се е превърнал в работния кон на федерацията в повечето корпоративни среди. Признато, парадигмата OAuth2 / OpenIDConnect набира сцепление, но SAML2 остава разпространен, особено в големите организации. Можете да видите SAML2, използван за:

  • Достъп до Google Apps и Google Mail
  • Azure Office 365
  • SalesForce.com
  • Конзола за управление на AWS
  • JEE приложения, които използват Container Managed Security

В един момент вашата собствена организация ще трябва да се справи с Single Sign On на уеб приложенията (независимо дали са отглеждани в домашни условия, SaaS или някаква друга трета страна). SAML2 е стандартът за дефакто в предприятието за постигането на това през почти последното десетилетие (макар че през последните няколко години OpenID Connect и OAuth2 печелят). Ако това са нови концепции за вашата организация, тогава в един момент вашият бизнес партньор ще ви каже да се интегрирате с доставчик на трета страна, доставчикът ще ви каже да подкрепите SAML, а вътрешният ви отдел за сигурност на информацията ще ви каже, че светът е в край. Ако това ви звучи познато, вие идвате на правилното място

Случаи за използване на SAML 2.0

В този и бъдещите публикации ще обхванем следните случаи на използване на SAML 2.0:

  1. Единно влизане в уеб приложението за доставчик на услуги (SP) (SSO)
  2. Web App SSO-иницииран доставчик на идентичност (IdP)
  3. SOAP Услуги и SAML 2.0
  4. REST API и SAML 2.0
  5. Еднократно излизане

Използвайте случай 1: Единично влизане в SP-инициирано уеб приложение

SP-инициираното уеб приложение SSO е едно от най-често срещаните приложения на SAML. Той е част от SSO профила на уеб браузъра, дефиниран в раздел 4.1 от спецификацията на профили SAML 2.0. Заедно с HTTP POST, HTTP GET и HTTP Artefact Bindings, които са дефинирани в спецификацията SAML 2.0 Bindings, тази спецификация определя детайлите за това как работи SP-инициираният SSO. В този сценарий има доставчик на идентичност (IdP) и доставчик на услуги (или доверяваща страна). Има и потребителски агент (обикновено браузър) и потребител, който трябва да бъде удостоверен и упълномощен да получи достъп до ресурса, хостван от доставчика на услуги. Този желан резултат може да бъде постигнат по няколко различни начина в зависимост от конкретния случай на употреба; Представям ви обща комбинация от дизайнерски решения, които са в рамките на спецификацията.

Фигура 1: Иницииран от доставчика на услуги SAML-базиран уеб приложение за единичен вход (SSO)

Профилът SAML 2.0 предоставя подробно описание на случващото се на Фигура-1, която започва на страница 16, ред 404.

През 2012 г. аз представих на Red Hat Summit за интеграция в сигурността и федерация със средния софтуер JBoss (съсредоточен върху PicketLink, неговия федерален слой за идентичност). Един от трите обхванати сценария за интеграция на сигурността беше SP-Initiated Web App SSO с две уеб приложения. Този пример дойде от това представяне. Следващата диаграма показва стъпките, включени в SP-Initiated SSO с две приложения и IdP, използвайки JBoss EAP и PicketLink.

Фигура 2: Подробен изглед на пренасочвания, базирани на SAML2 SSO в JBoss + PicketLink

Фигура 2 показва уеб браузър (потребителски агент), взаимодействащ с две уеб приложения, хоствани в различни JBoss контейнери. IdP удостоверява потребителя и издава SAML твърдение, на което се доверяват сървърите на приложения.

В стъпка 1 потребителят стартира началната страница на приложението Продажби. Контейнерът JBoss прихваща заявката, не намира информация за удостоверяване и връща съобщение за пренасочване 302 (с параметър SAMLRequest), което инструктира браузъра да изпрати заявката до предварително конфигурирания IdP. В стъпка 2, пренасочената заявка се изпраща до PicketLink IdP; Параметърът SAMLRequest съдържа съобщение AuthnRequest, кодирано от base64 (описано по-долу). Това съобщение съдържа подробности, необходими на IdP за обработка на удостоверяването на потребителя за приложението Продажби. Отговорът за стъпка 2 е форма за вход, в която потребителят може да въведе потребителски потребител и парола, тъй като потребителят не е удостоверен срещу IdP. В стъпка 3 потребителят е въвел идентификационни данни и е кликнал да изпрати. Практикуващите от JEE ще разпознаят HTTP POST на / idp / j_security_check като стандартния механизъм за удостоверяване на защитата, управляван от контейнери на сервлет, за автентифициране въз основа на формата. Ако потребителят е удостоверен успешно, се връща друго съобщение за пренасочване 302 - пренасочване към оригиналната крайна точка на IdP.

Стъпка 4 е преиграване на AuthnRequest, изпратен до IdP с информация за удостоверяване (бисквитка JSESSIONID, която се връзва обратно към автентифицирана сесия за защита); отговорът за стъпка 4 е пренасочване обратно към целевата страница на приложението Продажби с параметър SAMLResponse (описан по-долу), който съдържа SAML твърдение. Стъпка 5 е пренасочено повикване, изпращано до приложението Продажби с параметъра SAMLPResponse. Контейнерът JBoss извлича и утвърждава стойността SAMLPResponse и изложението SAML, което съдържа. Етапите на валидиране са описани в твърдения и протокол SAML 2.0. Предполагайки успех, контейнерът създава контекст на защита за потребителя и обработва заявката за приложение - изграждане на страницата за приветствие на приложението Продажби. Стъпка 6 извлича GIF изображение

На стъпка 7 потребителят осъществява достъп до приложението Employee във втория контейнер JBoss. Заявката не съдържа информация за сесията за сигурност; така, JBoss отговаря с 302 съобщение за пренасочване към IdP - точно както преди. В стъпка 8 браузърът изпраща AuthnRequest съобщението до IdP. Потребителят вече е удостоверен срещу IdP; IdP вижда, че заявката на браузъра съдържа информация за удостоверена сесия за защита за потребителя, обработва съобщението AuthnRequest, генерира съобщение SAMLPResponse и го поставя в параметър SAMLResponse като част от поредното пренасочване обратно към приложението Employee.

В стъпка 9 браузърът изпраща HTTP GET съобщение до целевата страница на приложението Employee. Контейнерът JBoss прихваща заявката, извлича SAMLPResponse съобщението, валидира го, утвърждава изявлението SAML, което съдържа и изгражда контекст на защита за сесията на потребителя. Контейнерът връща страницата за приветствие на служителя с бисквитка JSESSIONID за проследяване на новата сесия за сигурност. Стъпка 10 е заявка за изображение на страницата за посрещане на служителя.

Фигура 2 споменава две интересни структури от данни, които си струва да разгледаме по-подробно: SAMLRequest и SAMLResponse.

В горния пример се използва HTTP GET свързването и параметърът на заявка на заявка SAML съдържа базова64 кодирана структура на данни AuthNRequest, която изглежда нещо като следното:


   https://app1.levvel.io/login 

Елементът AuthnRequest съдържа елемент на Issuer и няколко забележителни атрибута (ProtocolBinding, AssertionConsumerServiceURL). Елементът Издател предоставя на аудиторията полученото твърдение за SAML (това ще се появи в информацията за аудиторията). Атрибутът AssertionConsumerServiceURL предоставя URL адреса, към който IdP трябва да пренасочва потребителя (с параметър SAMLResponse) след удостоверяване. Атрибутът ProtocolBinding определя кое свързване трябва да се използва. Параметърът SAMLResponse съдържа структура данни на Response, подобна на следното:



  https://idp.levvel.io/sso/saml2/token 
 
  
   
   
   
    
     
     
    
    
     kdmrndicowplkqdmduc = 
   
  
   [пропуснато за краткост ...] 
  
   
     [пропуснат за краткост ...] 
   
  
 
 
  
 
 
  [пропуснат за краткост. Вижте пример тук ...]
 

Ние покрихме твърдението SAML в първия пост от тази поредица. Елементът Response съдържа елементи на издател, подпис, статус и твърдение.

  • Елементът на издателя съдържа URL адрес, описващ IdP, генериращ тази SAMLPResponse.
  • Елементът за подпис съдържа подпис над елемента за отговор.
  • Елементът на състоянието съдържа състоянието на обработката на AuthNRequest.

Има две форми на кодиране за тези структури от данни: кодиране на URL (използва се с HTTP GET) и кодиране на формуляри (използвано с HTTP POST). Вижте спецификацията за свързване на SAML 2.0 за повече информация.

Както е отбелязано на фигура 2 и неговото описание, браузърът пренасочва SAMLPResponse към SP, което валидира подписа и друга информация в SAMLPResponse и SAML Assertion. Ако бъдат потвърдени всички валидации, на сървъра на приложения за SP ще бъде създаден контекст на защита. Изложението SAML обикновено не се пренебрегва в този момент на SP (някои JEE сървъри за приложения ще запазят копие на оригиналното твърдение за SAML, кеширано в контекста на сигурност); тя е абсолютно пренебрегвана след това от браузъра. В зависимост от използваната технология на сървъра за приложения, някои видове бисквитки за проследяване на сесия (или подобен механизъм) ще бъдат използвани за проследяване на сесията на защита.

Всеки доставчик, който поддържа Web App SSO за доставчик на услуги, има какафония от конфигурационни параметри, които могат да бъдат умопомрачителни. Работих с WAS, JBoss, TAMeb / WebSEAL и други платформи, които поддържат SAML2. Нито една от тях не беше проста за инсталиране за първи път в нова среда. Навлизането в подробностите на която и да е от тези платформи е извън обхвата на тази публикация, ако имате нужда от помощ при настройката на SAML2-базирана Web App SSO на която и да е платформа, свържете се с мен.

Използвайте Случай №2: Web App SSO - IdP Initiated

Web App SSO, иницииран от доставчика на идентичност, е подмножество от стъпките, описани в Use Case # 1. По-специално, стъпки от 5 до # 6 в общата последователност, инициирана от SPS, представляват стъпките, включени в IdP-инициираното уеб приложение SSO. Това е най-простата форма на Web App SSO, дефинирана от спецификацията SAML 2.0. Интересното е, че това е единственият тип SSO Web App, дефиниран от спецификацията SAML 1.1. Стъпките, включени в IdP инициираното уеб приложение SSO са:

  1. Удостоверете срещу IdP (детайлите са силно специфични за контекста).
  2. Пренасочена към страница със списък на SP-та, които са се регистрирали с IdP, които са представени като списък с връзки или меню.
  3. Заявката е изпратена до крайна точка на IdP, която генерира SAMLPResponse съобщение и връща страница в браузъра, която съдържа формуляр, който трябва да бъде изпратен на доставчика на услуги, който съдържа SAMLPResponse съобщение.
  4. Потребителят изпраща този формуляр до ACS URL адреса на доставчика на услуги.
  5. Доставчикът на услуги валидира съобщението SAMLPResponse и изложението SAML, което съдържа в спецификацията SAML 2.0. Приемайки успех, Доставчикът на услуги изгражда Контекст на сигурност за сесията на потребителя. Потребителят се пренасочва към целевата страница на приложението на доставчика на услуги.

Фигура 3: Идентифициран доставчик на идентичност (IdP) Идентифициран SAML базиран уеб приложение с един вход (SSO)

Тъй като детайлите са силно зависими от IdP и са подобни на Use Case # 1, тук няма да навлизаме в повече подробности.

Продължавайте да наблюдавате, докато продължаваме проучването на случаите за използване на SAML2.