This information was last reviewed in July, 2018, by Scott Cantor.
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 Datadog.
Identity Provider Metadata
The GUI for Datadog has a panel for its SAML Configuration and the only mechanism it appears to support for establishing the IdP settings is via uploading a metadata file, which is unusual. Further, it has a significant bug that seems to cause it to populate itself with the wrong entityID by setting it to the location the IdP's SingleSignOnService. More on that bug later.
Service Provider Metadata
Datadog will produce SAML metadata via a link that's only accessible when logged into the admin page, so even if you wanted to trust it as a remote source (and you shouldn't), you can't.
The metadata is fairly extensive but also full of errors and nonsense. It includes obvious copied extensions and content taken from a Shibboleth example somewhere, even though it isn't using Shibboleth, and advertises itself as requesting attributes common to our community, including eduPersonPrincipalName, which I suspect it does not support at all. It also includes very rarely seen algorithm metadata, and includes algorithms that are absolutely broken, such as MD5. It can't be trusted.
I created my own copy of the metadata by stripping out much of the nonsense, as well as its signing key, which it doesn't use. It has a separate key for encryption, which I did use.
Since it does appear to be static metadata, I include below what I used as a sample (no idea if they will eventually change the key without warning or that sort of thing but I strongly suspect so, it expires in 2020). I did leave in the
WantAssertionsSigned flag, as this SP does appear to (incorrectly) require that.
There aren't a whole lot of settings involved, about the only one worth noting is the requirement for signed assertions, which can be triggered via the metadata. It does fail without that done.
They appear to require the HTTP-POST binding on the request side, so that may trip up some deployments.
Their requests also unilaterally specify a
<NameIDPolicy> element with an email-based
Format, so the IdP must be configured to support that or the request will fail (mentioned again below).
Encryption is supported. Logout is not.
A significant bug I noticed has to do with an apparently broken determination of the IdP's entityID, which in my copy is displaying as the URL to my IdP's POST endpoint, and not my entityID.
That shouldn't work, since it would cause an
<Audience> condition check failure during login. That means either the value displayed is not accurate or it's not checking the condition. The latter would be a serious bug if they don't perform other checking such as the
Recipient attribute. Given the requirement for assertion signing, one presumes they ignore the
Destination attribute in the
If they check none of this, the use of encryption is the only MITM mitigation preventing assertion "retargeting" from one SP to another. Because of the encryption, I didn't take the time yet to actually probe the system to determine the extent of the bug.
Example Shibboleth Configuration
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.
Required Profile Configurations
Assertion signing MAY be enabled via the configuration, but it's simpler to just specify the flag in the metadata per the example above.
Datadog does support some kind of just-in-time provisioning, but I did not experiment with that feature.
Datadog appears to demand and assume email-based identification of users via the standard
<NameID> format of
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, which it requests explicitly at runtime. The IdP must therefore provide that in its response.
Example Shibboleth Configuration
Refer to the NameIDGenerationConfiguration topic for a full treatment of NameID features.
Continuing with the example above, if you have an attribute definition named "mail" produced by your AttributeResolverConfiguration, release it to Datadog in your AttributeFilterConfiguration (example below).
Finally, to actually produce the necessary
<NameID>, modify saml-nameid.xml as shown:
Datadog does not appear to support attributes for login, but it may rely on them for just-in-time provisioning, don't know for certain. That might explain the metadata claiming to support the standard attributes for first and last name, but wouldn't explain the reference to eduPersonPrincipalName, since that certainly isn't the same as requiring an email address.
There's a "strict" option that requires SSO for non-admin access.