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

в css в функции url() указывается либо абсолютный путь до файла, либо относительный, причем относительно именно css файла. например если структура такая:

css/style.css
img/icon.svg

то в css будет

url('../img/icon.svg')

Попробуйте использовать вот эту фишечку у jQuery api.jquery.com/css

у вас на картинке больше похоже что вы столбцы пытаетесь подсвечивать

.col-sm-2:hover > div {
    border-style: solid;
    border-color: #35146d;
}

может можно чисто css обойтись?

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