Where should be configured Service Provider name and certificate

[guillaumeeb]

Hi,

Thanks for the work here !

I'm planning to try your module, and I have a question about the correct configuration for the Service Provider, where should I put the name and certificate of my SP in order for my IDP to identify it? Does this goes into the XML metadata file ?

[distortedsignal]

Hi @guillaumeeb! Thanks for the feedback.

This is only the second time I've worked with SAML as an auth technology and I'm not totally sure what you're trying to do here. I think it has something to do with setting up... something... in the SAML SP metadata. I'll be going over the relevant specs today and I'll get back to you with a response.

For now, can you try running through setting up the IdP first, and setting up the SP second? The location for the POST request should be {hub_ip_addr_and_maybe_port}/login?next= or {hub_ip_addr_and_maybe_port}/hub/login?next=.

Again, thanks for trying out the project! I'll get back to you (and hopefully I'll figure out how to support your use case) this week. I hope I can make this work for you! 😄

Please feel free to reach out via this issue or another issue any time. I love getting feedback like this! 😄

[distortedsignal]

Ok @guillaumeeb, I've done a little digging on this, and I think I've come up with a compromise.

I think I can add a static metadata.xml file for specifying the SAML's SP properties. I think we can call this (along with some other enhancements) version 0.0.3. I think that can release this week or next week.

Adding a configurable service name should be pretty easy after that, and I want to add some more docs and code coverage metrics. I think that would be a good 0.0.4 release. I think that either this month or next month should be a good time for that.

Going a little further, I think that SP-signed Authentication Requests are a bigger feature that I need some time to work on in a considerate manner. I'm not sure when I will get to work on that, so I think I want to put it into a 0.1.0 release (or 1.0.0, I'm not sure yet). I'm not sure when that will be out.

Sound good?

[guillaumeeb]

Hi @distortedsignal, thanks for being so reactive (much more than me apparently)!

I'm really no SAML expert, the person which is in my organization told me that he find it weird to have an SP which initiated a SAML exchange without identifying itself. He sait to me that usually, the SP initiate the Exchange with its identity : a name and associated key. Currently, you just redirect the authentification to the IDP, which means (again according to my colleague), that it is finaly and IDP initiated auth. This may not be a stopper in my case, but the real SP initiated request was more appealing to my colleague, also for security reasons.

It would be very nice if you could work on this. I can validate the features on my setup.

[distortedsignal]

Thanks for getting back to me @guillaumeeb! A few comments:

Sorry about the disappearing/reappearing issues. I'll talk to my company's GitHub admins, make sure that we're on the same page about what this repo's needs are and how to best accomplish them.

If you want to tag your SAML-savvy coworker, I would love to have them in this conversation as well. :)

I think that if I'm going to be making a large change to the authenticator like you suggest for true SP-initiated requests, that may have to be a minor point release (whereas to this point all releases have been "bug fix releases" according to SemVer). That sounds like a good thing to add - I'll make a new release for that! :)

Thanks for your help!

[rubdos]

Hi folks! Sorry for jumping in here. I seem to be in the same boat, my case being an organisation-wide Azure AD. Currently, this is what Azure returns:

I have been provided a .cer file, presumably indeed to identify the source of the request. What can I do to get this to work? I can spend some time to get this implemented and tested, if you need some help.

[tomcatling]

See my response to #66 for how I 'solved' this in AWS. If WantAuthnRequestsSigned="false" in the IDPSSODescriptor metadata then creating the SAMLRequest can be very simple. I'll try to refactor this into a proper PR since supporting un-signed AuthnRequests seems a sensible step towards supporting signed ones.

The most important bits are

• this change to the redirect logic
  https://github.com/tomcatling/jupyterhub-samlauthenticator/blob/8711c3dbb10c26d14b135ec9ebdbed02fe4b351c/samlauthenticator/samlauthenticator.py#L737-L749

• this function to build the AuthnRequest xml
  https://github.com/tomcatling/jupyterhub-samlauthenticator/blob/8711c3dbb10c26d14b135ec9ebdbed02fe4b351c/samlauthenticator/samlauthenticator.py#L786-L806