Доброе утро, ребята
Не могли бы вы немного помочь мне со следующей проблемой?
У меня есть механизм балансировки нагрузки DNS и псевдоним (hostAlias), который может указывать на host01 или host02
Я хочу настроить apache и shibboleth для работы с этим псевдонимом. Что происходит ...
Типы пользователей: https://hostAlias (он указывает на host01) apache host01: перенаправить на shibboleth shibboleth host01: перенаправить на **https://hostAlias.cern.ch/Shibboleth.sso/ADFS**
Теперь есть два случая. Либо на этот раз hostAlias снова укажет на host01, либо на host02. Если он указывает на host02, host01 не получит ответ и аутентификация завершится ошибкой.
Кроме того, что касается сертификатов ssl, я предполагаю, что каждому хосту понадобится свой собственный сертификат. право ? Нужен ли сертификат с псевдонимами DNS?
Заранее спасибо !
Сначала небольшое предостережение: я знаю, что такое shibboleth / делает, но не реализовал эту настройку, поэтому, хотя это можно определить, я могу придумать несколько ошибок, которые могут его сбить. Я предлагаю задать вопрос пользователи shibboleth list, так как там пользователи =)
То, что вы пытаетесь, должно «просто работать», пока вы можете связать поток аутентификации с host01 или host02, в конце концов, это SSO. Если вы действительно хотите направить пользователя обратно на основной домен в качестве «целевого», то есть вероятность, что он будет перенаправлен на другой хост и повторно авторизован для локального поставщика услуг. Это должно сработать, процесс потенциально может быть немного сложным с точки зрения пользовательского опыта, если они сразу перевернуты и пройдут долгое ожидание нескольких перенаправлений, или у них есть ручной шаг в процессе IDP для POST обратно на ваш сайт (т.е. Нет JavaSript или IDP, который плохо отслеживает сеансы). Итак, я думаю, вы попали в режим изменения в середине авторизации.
User GET requests hostalias.com/protected
User redir to idp.com/sso?shire=host01.hostalias.com/sso&target=hostalias.com/protected
<IDP auth>
User POST to host01.hostalias.com/sso
host01.hostalias.com/sso redir to hostalias.com/protected
Проблема может быть в том, что спецификация shibboleth заботится об использовании разных доменов для id / shire / target. Хотя я в этом сомневаюсь.
«Чистое» решение - это менеджер сеанса, который может делиться состоянием сеанса между вашими хостами. Если вы выполняли аутентификацию в приложении java, вы могли бы использовать общую базу данных или удаленный поиск, если локальный поиск не удался и т. Д. Вам, вероятно, понадобится это, если вы планируете горизонтальное масштабирование с помощью X-хостов. У демона SP есть некоторые варианты для общего состояния это, похоже, зависит от того, будет ли apache использовать SP для сеансов.
Другой вариант, если вы застряли, - изменить настройку аварийного переключения DNS. Если вы сопоставите любые новые аутентифицированные сеансы с именем хоста (host01 host02 host0n) Затем вы можете сохранить пользователя на этом хосте. Сделайте авторизацию для этого хоста. Тогда переключение на новый хост происходит только тогда, когда он не работает (или перегружен ...). Эта настройка может вызвать несколько проблем с балансировкой нагрузки, если ссылки на один хост начинают использоваться больше, и может потребовать небольшого управления. Я бы попробовал это, только если есть проблемы с выполнением двух вышеупомянутых.
Сертификаты SSL основаны на доступном имени хоста. Если у вас есть несколько имен хостов, которые вы хотите защитить для клиентов, вам, вероятно, понадобится несколько сертификатов. Если у вас есть несколько имен хостов поддоменов, вы можете вместо этого получить групповой сертификат. Для приведенной выше настройки я бы предложил подстановочный знак для публичного имени, host01 и host02 .HostAlias.com. Первый и третий методы, описанные выше, потребуют wildcard / нескольких сертификатов для покрытия клиентов, обращающихся к различным поддоменам.