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.
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.
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.
<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> |
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 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. |
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.
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.
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:
<!-- 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> |
<AttributeFilterPolicy id="Datadog"> <PolicyRequirementRule xsi:type="Requester" value="https://app.datadoghq.com/account/saml/metadata.xml" /> <AttributeRule attributeID="mail" permitAny="true" /> </AttributeFilterPolicy> |
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.