<div dir="ltr"><div dir="ltr"><div>hello,</div><div><br></div><div>having a strange issue with testing the 5.1.6 update. We use the tier docker containers, and noticed with the 5.1.6 update it was mentioned the rocky8 OS variant was going away in favor of rocky9/10<br><br>So I flipped my testing over to the 5.1.6 rocky9 tier container, and my metadata-providers.xml LocalDynamicMetadataResolver entries stopped working. They were working just fine under rocky8. FilesystemMetadataProviders work just fine, but they are a little unwieldy in our setup.<br><br>I noticed in the rocky9 release notes they updated openssl, and depreciated sha1 for cryptographic uses. I did remember that the LocalDynamicMetadataResolver does use sha1 to resolve digested entityIDs from a sourceDirectory. Don't think the sha1 piece is related, more of an interesting coincidence.<br><br>So I did some testing.<br><br>these will be bogus strings, but the idea is the same:<br><br>I have saml metadata in a directory with an entityID of '<a href="http://localtest.site.edu:8091/sso/metadata">http://localtest.site.edu:8091/sso/metadata</a>' in a file called 'localtest_site_edu.xml'</div><div><br></div><div>I have a LocalDynamicMetadataResolver pointing at the directory.<br><br></div><div>When I run debug logs in shibb and try and authenticate with the SP, I get messages like this:</div><div><br></div><div><br></div><div>------ LOGS FROM 5.1.6 running on rocky9 with LocalDynamicMetadataResolver ------</div><div><br></div><div>LocalDynamicMetadataResolver OurLocalMetadataProvider: Resolving metadata dynamically for entity ID: <a href="http://localtest.site.edu:8091/sso/metadata">http://localtest.site.edu:8091/sso/metadata</a></div><div><br>DEBUG [net.shibboleth.shared.codec.StringDigester:156] - Digesting input '<a href="http://localtest.site.edu:8091/sso/metadata">http://localtest.site.edu:8091/sso/metadata</a>' as charset 'UTF-8' with digest algorithm 'SHA-1' and output format 'HEX_LOWER'</div><div><br>DEBUG [net.shibboleth.shared.codec.StringDigester:178] - Produced digested and formatted output 'f4325ed353dcc638925265e7aa47b6dc457b77a4'</div><div><br>TRACE [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118] - LocalDynamicMetadataResolver OurLocalMetadataProvider: Attempting to load from local source manager with generated key 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'</div><div><br>TRACE [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:124] - LocalDynamicMetadataResolver OurLocalMetadataProvider: Found no target in local source manager with key 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'</div><div><br>DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractDynamicMetadataResolver:821] - LocalDynamicMetadataResolver OurLocalMetadataProvider: No metadata was fetched from the origin source</div><div><br>DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractMetadataResolver:542] - LocalDynamicMetadataResolver OurLocalMetadataProvider: Metadata backing store does not contain any EntityDescriptors with the ID: <a href="http://localtest.site.edu:8091/sso/metadata">http://localtest.site.edu:8091/sso/metadata</a></div><div><br>DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractMetadataResolver:708] - LocalDynamicMetadataResolver OurLocalMetadataProvider: Candidates iteration was empty, nothing to filter via predicates</div><div><br></div><div>------</div><div><br></div><div>When I go look on the running container filesystem for 5.1.6 running rocky9, I see the digested file referencing the metadata file I mentioned above is this:</div><div><br></div><div>f2743c7e3c397a27ceec8a2950f1a9994c1c3496.xml -> localtest_site_edu.xml</div><div><br></div><div>which doesn't match.</div><div><br></div><div>when I use the rocky8 image, both the logs and the container filesystem match with this:<br>f4325ed353dcc638925265e7aa47b6dc457b77a4.xml -> localtest_site_edu.xml</div><div><br></div><div>------ LOGS FROM 5.1.6 running on rocky8 ------</div><div><br></div><div>LocalDynamicMetadataResolver OurLocalMetadataProvider: Resolving metadata dynamically for entity ID: <a href="http://localtest.site.edu.edu:8091/sso/metadata">http://localtest.site.edu.edu:8091/sso/metadata</a></div><div><br></div>DEBUG [net.shibboleth.shared.codec.StringDigester:156] - Digesting input '<a href="http://localtest.site.edu.edu:8091/sso/metadata">http://localtest.site.edu.edu:8091/sso/metadata</a>' as charset 'UTF-8' with digest algorithm 'SHA-1' and output format 'HEX_LOWER'</div><div dir="ltr"><br>DEBUG [net.shibboleth.shared.codec.StringDigester:178] - Produced digested and formatted output 'f4325ed353dcc638925265e7aa47b6dc457b77a4'</div><div dir="ltr"><br>TRACE [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118] - LocalDynamicMetadataResolver OurLocalMetadataProvider: Attempting to load from local source manager with generated key 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'</div><div dir="ltr"><br>TRACE [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:121] - LocalDynamicMetadataResolver OurLocalMetadataProvider: Successfully loaded target from local source manager source with key 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml' of type: {urn:oasis:names:tc:SAML:2.0:metadata}EntityDescriptor<div>------</div><div><br></div><div>I have tried with multiple metadata files, all that work except with rocky9. I verified the metadata files are UTF8 with LF endings.</div><div><br></div><div>I am wondering if there is some sensitivity in string reading that is occuring in one process (generating the symlink digest file), and not the other(recomputing and searching for it), but I have no idea about that process, or if how i've outlined it above with two separate parts is even accurate.</div><div><br></div><div>Any thoughts?</div><div><br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font color="#888888">**</font><br style="color:rgb(136,136,136)"><div dir="ltr" style="color:rgb(136,136,136)"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Nathan Lewan<div>IT Engineer - Identity and Access Management</div><div>Division of Information Technology</div><div>University of Maryland<br></div></div></div></div></div></div></div></div></div></div>
</div>