IndexError: List Index out of range

[jameholme]

Traceback (most recent call last):
File "/usr/local/lib64/python3.6/site-packages/tornado/web.py", line 1699, in _execute     result = await result
File "/usr/local/lib/python3.6/site-packages/samlauthenticator/samlauthenticator.py", line 713, in get     login_handler_self)
File "/usr/local/lib/python3.6/site-packages/samlauthenticator/samlauthenticator.py", line 634, in _get_redirect_from_metadata_and_redirect handler_self.redirect(redirect_link_getter(saml_metadata_etree)[0], permanent=False)
IndexError: list index out of range

I am using the simple configuration where:

c.JupyterHub.authenticator_class = 'samlauthenticator.SAMLAuthenticator'
Where the SAML IdP's metadata is stored.
c.SAMLAuthenticator.metadata_filepath = '/PATH/TO/MYFILE.xml'

[distortedsignal]

Hi @jameholme! This looks like an issue with how the authenticator interfaces with your Metadata xml. Would it be possible to post the metadata xml file? If not, could you check what value your metadata xml has at the following XPath?

//md:SingleSignOnService[@Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect']/@Location

How I'm walking through this issue:

It looks like the error is being thrown here, and I'm not entirely clear what the XPath is since it's dynamically defined above that line. So reading up the code (since there isn't much down), we find that we are being called from here. It looks like that line sets the element to md:SingleSignOnService, and then we can more-or-less reconstruct the XPath from there. If you want to double-check my work, I would encourage you to turn on debug logging for the JupyterHub server - I'm not sure how to do this, but it seems like it should be straightforward?

[jameholme]

<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="URL REMOVED FOR REASONS"/>

Thanks for the help, this is my first rodeo

[distortedsignal]

@jameholme if this is your first SAML Rodeo, welcome! There's some really cool stuff about the tech - for example, the metadata xml is usually publicly available (here's a link to one of the metadata xmls from the services that I usually use, it should download a file). Just like it's ok to spread public keys around to whoever needs them, it's fine to spread the xml metadata around unless you have a company policy against it.

Looking at the XML snippet you posted, it looks like we're using different SAML bindings. It looks like you're using an HTTP-POST binding, and I'm looking for an HTTP-Redirect binding. The authenticator might work if you alter your metadata xml to say HTTP-Redirect where it currently says HTTP-POST, but this is a fairly off-the-rails configuration that we're setting up.

I think the best course of action would be to leave this issue open so that we know that we need to add HTTP-POST binding in the future, and let me know if you aren't able to get going with the advice in this post. Sound good?

[jameholme]

I have changed it to redirect, but it did not change anything and I still received those same errors.

Below is the XML with the stuff I was told to remove before I could send it to you (again thanks for your help!):

<?xml version="1.0"?>

-<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="COMPANYURL.COM" cacheDuration="DURATION" ID="ID">

-<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

-<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

-<ds:Reference URI="URI">

-<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<ds:DigestValue> VALUE </ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue> CERT </ds:SignatureValue>

-<ds:KeyInfo>

-<ds:X509Data>

<ds:X509Certificate> CERT </ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

-<md:IDPSSODescriptor WantAuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

-<md:KeyDescriptor use="signing">

-<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

-<ds:X509Data>

<ds:X509Certificate>CERT</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

<md:SingleSignOnService Location="COMPANYURL.COM" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-REDIRECT"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="employeeID"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="memberOf"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="mail"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="title"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="displayName"/>

</md:IDPSSODescriptor>

<md:ContactPerson contactType="administrative"/>

</md:EntityDescriptor>

[distortedsignal]

Ok, two things -

1. I'm not 100% sure how Python's XPath works, but it may be that the HTTP-Redirect value has to be case-matched exactly. Check this pdf around line 1026 to see the exact values for this field.
2. Bad news - currently we don't support signing the SAML Request. We can put that into the backlog, but I'm not sure when I'm going to get to working on it. This is a great opportunity for a pull request :)