405 Method Not Allowed' immediately after SAML response

JupyterHub Zero to JupyterHub on Kubernetes
, ,
1

Hi all - am seeking guidance.
I’m stuck during a helm installation within an enterprise kubernetes setting. Am using jupyterhub-samlauthenticator and we are getting what seems a valid SAML response as we would expect.

However after receiving this response we see a ‘405 Method Not Allowed’.

Jupyterhub does not proceed any further in terms of pod setup for the SAML authenticated user.

Would anyone know what is not being allowed ? What is the next step in the authentication/user startup process?

thanks in advance

2

Hi! Could you turn on debug logging and show us your hub logs?

3

I’m not sure I can get those logs out of the enterprise environment. But heres an accurate precis if it helps ?

Samlauthenticator:806] Starting SP-initiated SAML Login
Samlauthenticator:711] Got valid metadata etree
Samlauthenticator:723] Final xpath is […]
Log:189] 302 GET /jupyter/hub/login?next=%2F → [SAML URL]

Then using SAML-tracer I validate the SAML response

Then next line in jupyterhub log is…

Base:1339] No template for 405
Log: 189] 405 POST /jupyter (@ ip_address) 22.53ms

Does that help ?

4

I’m afraid not, DEBUG logs will contain a lot more information.

Another option is to step through the source code to find out where it’s failing:

5

Hi, I am facing same issue as @bytesemantics mentioned. Log level is set to debug but still the only log i see related to SAML is
Samlauthenticator:806] Starting SP-initiated SAML Login
Samlauthenticator:711] Got valid metadata etree
Samlauthenticator:723] Final xpath is […]
Log:189] 302 GET /jupyter/hub/login?next=%2F → [SAML URL]

6

this is not a solution - but describes how I traced the issue. :). YMMV

I opened up Debugging console in Chrome/DeveloperTools - and watched the SAML auth workflow. This allowed me to identify if the issue was at the SAML side or Jupyter side of the interface. Once I realised that SAML was authenticating successfully - I identified that the redirect URL to Jupyter was incorrect - and we fixed this.

Debug trace was non-evident (despite using a DEBUG level).