Как работает SAML/SAML2?

Question

[Дмитрий Александрович]

Всем привет, столкнулся я с такой штукой как Shibboleth и вообще с интеграцией SSO (Single Sign On). как я понял есть 2 стороны IdP(identity provider) и SP(service provider). IdP уже реализован с помощью Shibboleth, я же в свою очередь реализую SP. Есть 2 пути: использовать громоздкую связку которая мне очень не нравится из Shibboleth SP + Tomcat + Apache Http Server и как то к этому ещё приладить мой сервис на Python/Django или выкинуть всё это в мусор и попробовать приладить к Django модуль djangosaml2. Я выбрал второй вариант. Но всё равно для меня осталось тёмным лесом то как всё устроено. Первый камень за который я запнулся в этом болоте - metadata. Откуда она берется и куда она передаётся, как и с чем её есть? должна ли быть она статичной или генерироваться динамически? С какими ещё нюансами я могу столкнуться?

Answer 1

[Дмитрий Александрович]

В общем методом тычков и ошибок, выясняется следующий в моем понимании алгоритм (я выбрал вариант с djangosaml2 и буду описывать решение именно для этого случая). SP получает метадату, причем получить он её может как динамическим, так и статическим из файла:

'metadata': {
      'remote': [{
          "url": 'https://ololo-sso.com/Shibboleth.sso/Metadata'
      }],
      'local': [path.join(BASEDIR, 'remote_metadata.xml')],
}

Кстати из граблей, у меня вылезала ошибка: 'SPConfig' object has no attribute '_sp_authn_requests_signed' которую можно победить указав нужный ключик в SAML_CONFIG:

'service': {
    'sp': {
      ...
           "authn_requests_signed": "false",
      ...
    }
}

Метадата содержит всякую полезную и не очень информацию, в том числе ключи шифрования, и url-адреса обработчиков различных способов авторизации.
Далее при переходе на страничку авторизации у SP, сам SP на основе метадаты IdP формирует запрос и передает этот запрос редиректом через браузер на login-страницу IdP например:

https://ololo-sso.com/Shibboleth.sso/Login

Получая этот запрос, IdP уже узнает откуда пришел наш заблудший юзер и где он хочет авторизоваться. Более того если IdP не знает где взять метадату от вашего сервиса, он это узнает как раз из этого запроса, а уже после удачной авторизации отправит вашего пользователя обратно к вашему сервису.
Так же в подавляющем большинстве случаев IdP должен за ранее знать о существовании вашего сервиса, иначе он вас никуда не пустит.
Далее пока что не разобрался.