How to make SP initiated call.

[anshul24sharma]

First of all, I loved the code and explanation given. I am able to set everything up and it is working from the IDP side. But when I make a call SP side, it redirects to IDP but stops on 302 redirect to ADFS page. I think there is some kind of authentication and authrequest xml is needed from SP side to IDP to verify and redirect properly. Could you help me figure this out?

[distortedsignal]

Currently, this code doesn't fully support the SP-initiated SAML workflow. It's on the radar, and it's the biggest thing that I think needs to happen before 0.1.0 is going to be released. I'll probably get around to it sometime in the next month or two, but for right now, we're kind of stuck. Sorry. 😢

[anshul24sharma]

Alright. That's fine. But I was reading through the documentation and there was a mention of a status metadata.xml file or something that can be put along with the url that can be passed as a parameter from SP side. If you know about that, can you tell where would that status metadata fink would go? Or what parameters and how do I specify the parameters to url.

[distortedsignal]

The Authenticator currently provides Service metadata from ${jupyterhub_ip_and_port}/metadata and ${jupyterhub_ip_and_port}/hub/metadata - this is a fairly minimal subset of information about the service that helps IdPs such as PingFederate create endpoints for the Authenticator. There will still be a significant amount of admin setup to hook these services up.

You can see where the Authenticator specifies the URLs for the metadata xml here and you can see what information is provided at the URL by looking at the template that is assembled into the data here.

[anshul24sharma]

I see. Is there a way I can pass custom fields or a new metadata file along with the urls?

[distortedsignal]

You want to modify the metadata on the JupyterHub server itself? That is not a workflow I had considered. When I'm making the SP-initiated updates, I will try to support this workflow, but it might not be elegant. For right now, you could edit your jupyterhub config file to change what the jupyterhub server returns when you get those urls. Would that work? It would look kind of like this:

class OverridingMetadataGetter:
	async def get(self):
                anshul24sharmasXml = '''some xml metadata here'''
                self.write(xml_content)

c.JupyterHub.extra_handlers = [("/metadata", OverridingMetadataGetter), ("/hub/metadata", OverridingMetadataGetter)]

Docs here for updating the handlers: https://jupyterhub.readthedocs.io/en/stable/api/app.html#jupyterhub.app.JupyterHub.extra_handlers

[anshul24sharma]

Hey! I tried what you mentioned. I copied the following in jupyterhub_config.py with my own metadata in the anshul24sharmasXml variable:

class OverridingMetadataGetter:
	async def get(self):
                anshul24sharmasXml = '''some xml metadata here'''
                #self.write(xml_content)
                self.write(anshul24sharmasXml)

c.JupyterHub.extra_handlers = [("/metadata", OverridingMetadataGetter), ("/hub/metadata", OverridingMetadataGetter)]

But nothing is changed when I go to /metadata or /hub/metadata links, the metadata response is still as it was before. Do I need to do something else too? Also should it be 'anshul24sharmasXml' or 'xml_content' in self.write command. Anyway I tried with both and it doesn't work. Let me know if I am doing something different.

[anshul24sharma]

Hello! Specifying the static metadata through extra_handlers is not updating the metadata which is set default. Do you know what could be wrong here?

[distortedsignal]

There is a lot that could be wrong here. At this point, we're trying to hack through the JupyterHub Config file to add a handler and override the Authenticator's handler. That process is going to be fraught with peril, and we are way outside the recommended install path.

How about this - I'll try to get some time from my work to add an SP-initiated workflow to the authenticator, take some time to let people use custom xml metadata, and then I'll get back to you. Would that be ok?

[anshul24sharma]

That sounds great. Would be really helpful if I can have something like that. Thanks. Let me know.

[distortedsignal]

I'll tag you in the PR.

[anshul24sharma]

Hey! Just a small thought. Could you tell me how much it can take to use the custom xml metadata and make a new PR.

[distortedsignal]

Ok, let me see...

• Add a new traitlet to hold the custom metadata
• Edit the _make_sp_metadata function to return the custom metadata if the traitlet had content
• Add a test to confirm the new behavior
• Add documentation to let people know what the custom metadata should look like

If you want to take on one or all of these tasks, I would be happy to help you out with the others.

[anshul24sharma]

Sorry for the typo! I meant how much time it would take you to make a new PR.

But sure yeah. I am happy to help. I haven't worked with tartlet yet but I think we can add something like this:

class OverridingMetadataGetter: async def get(self): test_xml = '''some xml metadata here''' self.write(test_xml)

[distortedsignal]

For my timeline on this, I'm going to guess that 0.1.0 is going to be out before October. That will have the SP-initiated workflow enable, and it should have the metadata update. This is, however, a guess, and subject to change at just about any whim of business or developer. MIT code, etc.

[holzman]

Any updates? We've got a JHub instance and Ping identity IdP, and it would be great to redirect users to ping in the normal SP-initiated flow.

[dxunix]

I have tried this with Auth0 with the SP-initiated flow and it was successful. But i cannot do the same with the PingFederate server.
it works with

    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://****.us.auth0.com/samlp/****"/>
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://****.us.auth0.com/samlp/****"/>

but not with

        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://****/idp/SSO.saml2"/>
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://****/idp/SSO.saml2"/>

So I thought it would be a problem with the ping not the package itself?