ThousandEyes

This information was last reviewed in March, 2019, by Scott Cantor

Change Log:

This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.

This is a page for documenting Shibboleth integration with ThousandEyes

A link to their documentation/KB article on the SSO set up is https://success.thousandeyes.com/PublicArticlePage?articleIdParam=kA0E0000000CmnEKAS_How-to-configure-Single-Sign-On-SSO-Metadata

Identity Provider Metadata

There are three apparent options for setup under Organization → Security and Authentication: manual, static metadata import, and a dynamic option that does a "no verification" fetch of metadata from a URL on every user login. The latter might be viable I suppose, but I have only tried it with static configuration.

The usual fields are needed:

Login Page URL: https://idp.example.org/idp/profile/SAML2/Redirect/SSO

Logout Page URL: https://idp.example.org/idp/profile/SAML2/Redirect/SLO

Identity Provider Issuer: your entityID

Service Provider Issuer: you can change this but I would stick to the https://app.thousandeyes.com default

Verification Certificates: they actually do support more than one even when configuring manually

Service Provider Metadata

They have a metadata link published in their documentation. It's not terrible, but they do have the WantAssertionsSigned flag on incorrectly and the usual nonsense with NameID formats. They correctly include a key that's marked for signing only. It's notable that it's an expired self-signed certificate, which would be cooler if I thought it was intentional.

As always, I highly discourage loading it directly into the IdP and would suggest copying it locally and loading it from there.

Profile Requirements

They don't support encryption, but otherwise don't require any special behavior.

Example Shibboleth Configuration

Required Profile Configurations

SAML2.SSO

SAML2.Logout (if logout is desired)

Refer to the RelyingPartyConfiguration topic and be cognizant that creating overrides for every service is generally an inefficient use of the software. Consider identifying common requirements across services and create overrides tied to multiple services that share those requirements, or that reference profile configuration beans containing common settings.

Example relying-party.xml override

<!-- Container for any overrides you want to add. -->

<util:listid="shibboleth.RelyingPartyOverrides">

    <!-- other overrides... -->

    <beanp:id="example.DisableEncryption"parent="RelyingPartyByName">
        <constructor-argname="relyingPartyIds">
            <list>
                <value>https://app.thousandeyes.com</value>
            </list>
        </constructor-arg>
        <propertyname="profileConfigurations">
            <list>
                <beanparent="SAML2.SSO"p:encryptAssertions="false"/>
                <beanparent="SAML2.Logout"/>
            </list>
        </property>
    </bean>

</util:list>

Account Provisioning

The accounts have to be in place with an appropriate email address as the user ID.

NameID Requirements

It requires use of the NameID or one of a handful of bogus SAML Attributes, so the NameID is probably best. I doubt it checks the Format, but it claims to require specific ones, so I used the standard urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress Format to carry the data and triggered that via an <md:NameIDFormat> element in the SP's metadata. It

The application supposedly only supports email-based identification of users.

Attribute Requirements

It does support some non-standard attributes predefined to carry the email address, but I did not try them.

Other Considerations

Their logout is fascinatingly broken. It actually correctly implements at least the request half of a SAML logout, including signing and proper embedding of the NameID (though to be fair it might only do that if you pass it the email address in that form to start with). But despite all that, they do nothing to clear their own application session, so you may get logged out of the IdP but are still logged into the application itself. I did not have a convenient way to report that bug.