Page tree
Skip to end of metadata
Go to start of metadata

This information was last reviewed in July, 2018, 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 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.

Significantly edited Datadog metadata
  <EntityDescriptor entityID="">
          <mdui:DisplayName xml:lang="en">Datadog</mdui:DisplayName>
      <KeyDescriptor use="encryption">
        <dsig:KeyInfo xmlns:dsig="">
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
        Location="" index="1"

Profile Requirements

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 <Response>.

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.

Account Provisioning

Datadog does support some kind of just-in-time provisioning, but I did not experiment with that feature.

NameID Requirements

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:

Example saml-nameid.xml changes
	<!-- SAML 2 NameID Generation -->
	<util:list id="shibboleth.SAML2NameIDGenerators">

		<ref bean="shibboleth.SAML2TransientGenerator" />

		<ref bean="shibboleth.SAML2PersistentGenerator" />

		Add custom support for mail-based NameID, assumes you've released
		the source attribute (mail) to any SPs expecting to get it.
		<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
			p:attributeSourceIds="#{ {'mail'} }" />

Example attribute-filter.xml changes
	<AttributeFilterPolicy id="Datadog">
		<PolicyRequirementRule xsi:type="Requester" value="" />

		<AttributeRule attributeID="mail" permitAny="true" />

Attribute Requirements

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.

Other Considerations

There's a "strict" option that requires SSO for non-admin access.

  • No labels