С тех пор как все программное обеспечение активно уходит в облака, также активно развиваются технологии единого входа и авторизации для облачных систем.
Войдя на компьютер под своей учетной записью вы можете дальше пользоваться необходимыми облачными приложениями без необходимости придумывать и запоминать пароль к каждой системе.
Одной из таких технологий единого доступа является SAML это язык разметки (Security Assertion Markup Language), основанный на языке XML.
Эта технология разработана для обмена данными об аутентификации и авторизации.
Очень хорошее видео по знакомству с SAML . (Подробно о средствах идентификации в корпоративных сетях)
Подробный документ с описанием тут.
Язык SAML построен на следующих существующих протоколах:
• XML - Подавляющее большинство утверждений SAML представляется в виде совокупности XML-тегов
• XML Schema - Все утверждения SAML описаны используя XML-схемы
• XML Signature - SAML использует цифровую подпись(основанную на стандарте XMLDSig) для аутентификации и защиты сообщений
• XML Encryption - SAML 2.0 предоставляет возможность использования шифрованных идентификаторов, шифрованных атрибутов и шифрованных утверждений, используя XML Encryption
• HTTP - SAML использует протокол HTTP в качестве транспортного протокола
• SOAP - SAML использует SOAP 1.1
Структура SAML
Профиль SAML - конкретное описание сценария, использующего комбинацию выбранных утверждений, протоколов и привязок.
Привязка SAML определяет как запросы и ответы отображаются в стандартные сообщения или коммуникационные протоколы. Одной из важных привязок языка является SOAP-привязка.
Протокол SAML описывает как конкретные элементы SAML инкапсулируются в запросы и ответы,а также правила обработки сущностей SAML.
Утверждения SAML
Утверждения SAML — это высказывания службы идентификации (identity authority) о конечном пользователе — человеке или компьютере. Подобно Active Directory, служба идентификации является доверительным источником заключений об аутентификации и авторизации. Во многих организациях Active Directory используется как служба идентификации, содержащая параметры безопасности многочисленных приложений. Утверждение — это ответ на запрос типа "Может ли Джон Смит получить доступ к серверу отдела кадров?"
Существуют три вида утверждений: авторизации, аутентификации и атрибута. Каждое из них содержит набор общих элементов: предмет, условие и аутентификационное высказывание ("Таблица элементов").
Варианты использования
Основными участниками процесса идентификации пользователя являются:
- браузер пользователя
- Identity Provider (IdP) - провайдер идентификации
- Service Provider (SP) - сервис провайдер, по простому поставщик услуг
Есть два варианта реализации единого доступа SSO (Single Sign On).
Первый сценарий IdP-инициирующий (IdP Initiated), когда пользователь сначала обращается к IdP, где он аутентифицируется, и затем переходит на SP. IdP создает утверждение, определяющее состояние аутентификации пользователя на IdP, перенаправляет браузер пользователя к SP, который обрабатывает утверждение и создает локальный контекст безопасности для пользователя. Такой подход используется в основных окружениях, но требует, чтобы IdP был сконфигурирован с внутренней ссылкой на SP. Иногда используется специальное связывающее поле, называемое RelayState, для координации сообщений и действий IdP и SP, например, позволяя на IdP (на котором был инициирован SSO) указать URL требуемого ресурса на SP.
Второй сценарий это SP-инициирующая (SP Initiated) модель веб-SSO. В этом сценарии пользователь обращается к ресурсу на SP. Предполагается, что пользователь еще не аутентифицирован, поэтому SP перенаправляет пользователя к IdP для выполнения аутентификации. IdP создает утверждение, доказывающее аутентификацию пользователя, и перенаправляет пользователя обратно к SP. SP анализирует полученное утверждение и определяет, предоставлять ли пользователю доступ к ресурсу.
Эта модель предполагает, что утверждения SAML будут пересылаться между IdP и SP в обе стороны. Для профиля веб-SSO в основном используются два сообщения SAML: сообщение запроса аутентификации посылается от SP к IdP, и сообщение ответа, содержащее утверждение SAML, посылается от IdP к SP.
На этой схеме изображены шаги по авторизации в почту Google:
1. Пользователь предпринимает попытку входа в Службы Google, например в Gmail.
2. Google генерирует запрос аутентификации SAML. Запрос SAML шифруется и добавляется в URL, предоставленный владельцем домена как адрес системы SSO.
Параметр RelayState, содержащий URL приложения Google, в котором пытается авторизоваться пользователь, также добавляется в URL. Предполагается, что этот
параметр будет передан обратно без изменений, его проверка не требуется.
3. Google переадресовывает браузер пользователя на URL, включающий запрос аутентификации SAML к системе SSO владельца домена. URL переадресации может выглядеть так..
https://idp.uni.nl/sso?SAMLRequest=fVLLTuswEN0j8Q…c%3D
4. Провайдер аутентификации расшифровывает запрос SAML, извлекает из него URL Google ACS (Assertion Consumer Service) и URL приложения, в котором пытается
авторизоваться пользователь (параметр RelayState) и аутентифицирует пользователя, например, проверяя его cookies или запрашивая его логин и пароль.
<AuthnRequest ID="kfcn...lfki"
Version="2.0"
IssueInstant="2013-02-05T08:28:50Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
ProviderName="google.com"
AssertionConsumerServiceURL="https://www.google.com/a/uni.nl/acs"
>
<Issuer>google.com</Issuer>
<NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
/>
</AuthnRequest>
5. Провайдер аутентификации генерирует ответ SAML, включающий имя пользователя в Службах Google. В соответствии со спецификацией SAML 2.0, ответ подписывается публичным и закрытым ключами DSA или RSA.
6. Провайдер аутентификации возвращает браузеру ответ SAML вместе с параметром RelayState и обеспечивает его передачу в Google's ACS. Например, это можно
сделать включив ответ SAML и целевой URL в форму, чтобы пользователь мог отправить ее данные Google, или сделав автоматическую отправку данных такой формы на JavaScript.
<Response
Version="2.0"
IssueInstant="2013-02-05T08:29:00Z"
Destination="https://www.google.com/a/my.uni.nl/acs"
InResponseTo="kfcn...lfki">
<Issuer>https://idp.uni.nl/</Issuer>
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</Status>
<Assertion Version="2.0" IssueInstant="2013-02-05T08:29:00Z">
<Issuer>https://idp.uni.nl/</Issuer>
<Subject>
<NameID>alice</NameID>
<SubjectConfirmation ...>
<SubjectConfirmationData
NotOnOrAfter="2013-02-05T08:34:00Z"
Recipient="https://www.google.com/a/my.uni.nl/acs"
InResponseTo="kfcn...lfki"/>
</SubjectConfirmation>
</Subject>
<Conditions
NotBefore="2013-02-05T08:28:30Z"
NotOnOrAfter="2013-02-05T08:34:00Z">
</Conditions>
<AuthnStatement
AuthnInstant="2013-02-05T08:29:00Z"
SessionNotOnOrAfter="2013-02-05T16:29:00Z >
</AuthnStatement>
</Assertion>
</Response>
7. Google ACS проверяет ответ SAML, используя публичный ключ провайдера аутентификации. Если ответ успешно проверен, ACS переадресовывает пользователя на
URL запрошенной им службы. В результате пользователь оказывается авторизован в Службах Google и переадресован на URL запрошенного им приложения - Gmail, Календарь Google и т. д.
