Shibboleth 4.2.1. Identity Provider and OneTrust (SP)

[Nate Klingenstein]

Stefano,

> I saw through the docs that other IDPs (Okta and Azure by example) manage the certificates separately.

I think I type for everyone when I write this is the day the music stopped.

> Is it possible to do the same with Shibboleth IDP?

No.  Shibboleth only loads certificates from provider metadata.

This is probably spec-legal given the vintage of SAML 2.0, but I need much more beer to actually go look.

> Second obstacle: NameIDFormat only unspecified (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified), since in the past I had the same issue with the metadata provided to me at the time (with Google as SP) i fixed in the same way, could be a source of problems?

It could, depending on application design.  Instead of changing the metadata to match your needs, it'd be best to configure your IdP to release the appropriate attribute as an unspecified NameID.

     <!-- md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat-->
     <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

> Third obstacle: I still not able to log-in on OneTrust

I'm guessing this is because of the NameIDFormat change you made.

> 2022-05-13 10:14:06,577 - 10.xx.xx.15 - WARN [org.opensaml.saml.common.binding.SAMLBindingSupport:94] - Relay state exceeds 80 bytes: ZW1haWw6cy5icmlkaUBlbmdpbnNvZnQuY29tJm9yaWdpbkhvc3Q6ZW5naW5zb2Z0Lm15Lm9uZXRydXN0LmNvbQ==

Completely normal log.  This is just basically a legacy warning about URL length that I think may be related to some specification.

You may find other fun things after the NameID is aligned, but that's all I can do for now.

Take care,
Nate