В общем методом тычков и ошибок, выясняется следующий в моем понимании алгоритм (я выбрал вариант с 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 должен за ранее знать о существовании вашего сервиса, иначе он вас никуда не пустит.
Далее пока что не разобрался.