<div dir="ltr">The VMWare support staff has finally gotten back to us, claiming we lack the following:<div><br></div><div>• Signingkey<br>• At least one of the artifact resolution endpoint uses SOAP<br></div><div><br></div><div>The signing key seems weak. Our metadata contains the key elements:</div><div><br></div><div> <KeyDescriptor><br> <ds:KeyInfo><br> <ds:X509Data><br> <ds:X509Certificate><br></div><div> [....]</div><div><br></div><div>While it does not explicitly include <KeyDescriptor use="signing">, I don't think this has ever been a problem with other SPs that required signing. It seems like they just used the provided non-specific X509 cert for signing and/or encryption as needed. Are they being unnecessarily picky here or is our metadata not really compliant with the specs?</div><div><br></div><div>Re the SOAP endpoint, I think this is also the first time we've had an SP require one. We may have (probably?) had them in our metadata at some point but we possibly stripped them out because they seemed to be disused. Is there a way to confirm that we have support for the SOAP artifact resolution endpoints enabled (or not disabled, if enabled by default)? And assuming we support them, what should they look like in the metadata? We currently only have the following SSO endpoints in our metadata:</div><div><br></div><div> <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"<br> Location="https:/IDP_HOST/idp/profile/Shibboleth/SSO" /><br> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"<br> Location="<a href="https://IDP_HOST/idp/profile/SAML2/POST/SSO">https://IDP_HOST/idp/profile/SAML2/POST/SSO</a>" /><br> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"<br> Location="https:/IDP_HOST/idp/profile/SAML2/POST-SimpleSign/SSO" /><br> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"<br> Location="<a href="https://IDP_HOST/idp/profile/SAML2/Redirect/SSO">https://IDP_HOST/idp/profile/SAML2/Redirect/SSO</a>" /><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 10, 2023 at 4:13 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> What we have seen is when they try to import our metadata, they get some<br>
> "Invalid static metadata" error, but unfortunately nothing more specific than<br>
> that.<br>
<br>
Presumably then you'd have to start munging the metadata to remove extensions and unusual content to strip it down to bare bones.<br>
<br>
But it's not sensible that they could be getting so far as issuing requests to you while being unable to import the metadata since they'd have no way to know your endpoint.<br>
<br>
-- Scott<br>
<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="arial, sans-serif">Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> ::: UH Information Technology Services<br>minutas cantorum, minutas balorum, minutas carboratum descendus pantorum</font></div></div>