Datadog

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="https://app.datadoghq.com/account/saml/metadata.xml">
    <SPSSODescriptor
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
      WantAssertionsSigned="true">
      <Extensions>
        <mdui:UIInfo>
          <mdui:DisplayName xml:lang="en">Datadog</mdui:DisplayName>
        </mdui:UIInfo>
      </Extensions>
      <KeyDescriptor use="encryption">
        <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
          <dsig:X509Data>
            <dsig:X509Certificate>
MIIF1zCCA7+gAwIBAgIJAMYeJwbURqtKMA0GCSqGSIb3DQEBCwUAMIGBMQswCQYD
VQQGEwJVUzELMAkGA1UECAwCTlkxETAPBgNVBAcMCE5ldyBZb3JrMRAwDgYDVQQK
DAdEYXRhZG9nMRowGAYDVQQDDBFhcHAuZGF0YWRvZ2hxLmNvbTEkMCIGCSqGSIb3
DQEJARYVc3VwcG9ydEBkYXRhZG9naHEuY29tMB4XDTE3MDYwMTE5MzAzN1oXDTIw
MDUzMTE5MzAzN1owgYExCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJOWTERMA8GA1UE
BwwITmV3IFlvcmsxEDAOBgNVBAoMB0RhdGFkb2cxGjAYBgNVBAMMEWFwcC5kYXRh
ZG9naHEuY29tMSQwIgYJKoZIhvcNAQkBFhVzdXBwb3J0QGRhdGFkb2docS5jb20w
ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDbYH6LIUAE3UvlDiUSn3aL
YcKQ4HF6Zhgrckt8svCKCtxVFPFhH2kt8/GYMqPuqdP/flOKAAjLhum067c/f6QW
V8SozRM8zJ8bLDBfj/bOKUAxfi/atLU4JZGA/JzLHxPQ2vRZbTaQbziemnz7ROAw
m6gZzXM++qvYfJeLchfOFTO5Vi+3pYulf9+yXsigMJVwZHyZJaGlW6iAXCw+1s2R
n4P1JGngNp495/VrTg6PiAxwva7Q9Z99geD+f+3hyhwi4wluegzyoU5XvbyqAtwV
pGclUGdgRicVbCLvQ1EpGXBkhqDYCju+00PMDh06U6rxNkrSjJSpAzjzg6TpqtSl
M6lYwNGeO4hPiYjv5eNq+uTJLQVH6pDkYM8n8U/yDtJAuRauTyPBx4971UA+AGXG
k3LXbWj9NIuA2RcK9vH7t7IGOa9vixSIyIf5ycRKGeLrr5Wm48fUtz2APVvhFU4m
i10HVM5hoN67yAZI3cXaWc/z/AMdWGa4dahaYLp9YSt+hs3PcbXVjGQCpYJU2/YL
TXOn1fJCTotoXiwe083+LYDPiD5e8v+JAUHZKqt/uH/BNm7Namm5Z+PlwD9j2iCr
m0l3iZDiZgpLPSQGHiUezG560zHkJn2xxLt0b8p059d7o2O8IWyZLjQz5ktx0o5a
AjH5oU4p/PDx9OcwghZntQIDAQABo1AwTjAdBgNVHQ4EFgQUypc+eAsQLl5+NGZI
d9CWXZ4DLFwwHwYDVR0jBBgwFoAUypc+eAsQLl5+NGZId9CWXZ4DLFwwDAYDVR0T
BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAgEAZUcwGtXNOMGtxccE6CRlNGUABjn+
KaOf+9U+wQDI9UjbwK5ILKWHUTy3W+0xTFFjonVVhWCIIYI3A3Du4PDMxh6+MTzt
QtBWZ6Ko1TjEOqPd6pogN8WRw/YCHPBc0TQqz5Fc/jam1aod7oOs5e3BMozoXEHt
m7otC0CLLf9A7mfZHnO2XtYNwirqcUEYRUC8K1jbAyckANaWQ2XY8J9bsWG5Ihh2
tjwY+rCFCk7OYWnkopTr0GIcDPMm/l/7LEz1opQl4rhMHZkqW/6gvHMZIxQMBclS
3/Aa8dkF8dzaY8ZtbJNa+EwvBjxZBKQPFrlWYdcEpPgFFPUjcp7Vg+sa6DEKeaHp
8GukVujtfJYdE7cG8EuySlkm4bVSz/jtL1Zple/maRf9dt0P0h2Yn5hw9GCZ15BV
a25ffjlFJGnOqJt/HETRBKRBt3+RJvicyCX+z8HHIgeN/j2tPlJmJ6kH1Wrwq6/U
S2EBygbVEMdSZ0V1W9D8JGZ89K4Vch09ne97k/nFFDT9TAqdwHiJlqCJzndagwFJ
fACpejqMou1cJyyqhzeHCRg1+9nAWVtvm68W/r/EJhsZq1oOYDfXKx8xIAIRwocy
Heg+Ypa6LNnTC433OJJwIBLiZwEwDg4mzPvXcnRcy3RvKVc1u9ZH9LifrZhBGqe+
hjWdG/0un8w4niw=
            </dsig:X509Certificate>
          </dsig:X509Data>
        </dsig:KeyInfo>
      </KeyDescriptor>
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
        Location="https://app.datadoghq.com/account/saml/assertion" index="1"
        isDefault="true"/>
    </SPSSODescriptor>
  </EntityDescriptor>

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

SAML2.SSO

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:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
			p:attributeSourceIds="#{ {'mail'} }" />

	</util:list>

Example attribute-filter.xml changes

	<AttributeFilterPolicy id="Datadog">
		<PolicyRequirementRule xsi:type="Requester" value="https://app.datadoghq.com/account/saml/metadata.xml" />

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

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.