Мы пытаемся настроить веб-приложение (django) в Google App Engine, подключенное через SAML к нашему idP, Okta. Это должно быть выполнено как настраиваемое гибкое приложение из-за требований к двоичному файлу, что делает его в основном развертыванием контейнера. Запуск его локально с помощью Gunicorn (включая конфигурацию SSL) работает безупречно, но развертывание его в Google не так уж и много.
Проблема в том, что перенаправление idP на sP не работает с
Traceback:
File "/env/lib/python3.6/site-packages/django/core/handlers/exception.py" in inner
34. response = get_response(request)
File "/env/lib/python3.6/site-packages/django/core/handlers/base.py" in _get_response
115. response = self.process_exception_by_middleware(e, request)
File "/env/lib/python3.6/site-packages/django/core/handlers/base.py" in _get_response
113. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/env/lib/python3.6/site-packages/django/views/decorators/csrf.py" in wrapped_view
54. return view_func(*args, **kwargs)
File "/env/lib/python3.6/site-packages/django_saml2_auth/views.py" in acs
159. resp, entity.BINDING_HTTP_POST)
File "/env/lib/python3.6/site-packages/saml2/client_base.py" in parse_authn_request_response
714. binding, **kwargs)
File "/env/lib/python3.6/site-packages/saml2/entity.py" in _parse_response
1213. response.require_signature = require_signature
Exception Type: AttributeError at /sso/acs/
Exception Value: 'NoneType' object has no attribute 'require_signature'
Текущая теория заключается в том, что прокси-сервер Nginx перед приложением каким-то образом вмешивается в запрос POST и нарушает утверждение SAML, но такие настройки или документация к нему еще не найдены.
Мы будем очень благодарны за некоторые свежие идеи.
Как было предложено выше, добавление записи ASSERTION_URL в словарь SAML2_AUTH в вашем файле settings.py Django решит проблему Exception Value: 'NoneType' object has no attribute 'require_signature' ошибка.
Я хотел бы добавить некоторые детали, которые помогли мне решить эту проблему. В моем случае, при использовании dockerized django, работающего с AWS Fargate, интегрированным с Okta, конфигурация выглядит так:
'ASSERTION_URL' : f"https://{ENV_VAR('YOUR_APP_URL')}" if "YOUR_APP_URL" in os.environ else 'http://127.0.0.1:8000',
Использование условия для запуска на локальном хосте также для тестирования. Также обратите внимание на предыдущий https протокол помещен туда для ясности того, что мы пытаемся решить.
При отсутствии этого параметра, помимо упомянутой выше ошибки, еще одна ошибка из выходных журналов, вероятно, более полезна, чтобы понять, почему 'ASSERTION_URL' конфиг необходим:
"https://your-domain/saml2_auth/acs/ not in ['http://your-domain/saml2_auth/acs/']"
Конечно, после прочтения этой темы я снова прочитал документацию по адресу https://github.com/fangli/django-saml2-auth/ где сказано:
«По умолчанию django-saml2-auth будет проверять адрес поставщика услуг ответа SAML на соответствие фактическому хосту и схеме HTTP-запроса. Если это значение установлено, оно будет проверяться вместо этого на ASSERTION_URL - идеально, когда django работает за обратным прокси».
Проблема была достаточно простой: конфигурация обратного прокси меняет HTTP-запрос (схема HTTPS на HTTP), что делает плагин Okta (https://github.com/fangli/django-saml2-auth) терпят неудачу с неясной ошибкой. Добавление записи ASSERTION_URL в dict SAML2_AUTH в файле settings.py Django делает свое дело.