IdP integrating with VMWare Horizon as an SP?

[Baron Fujimoto]

The VMWare support staff has finally gotten back to us, claiming we lack
the following:

• Signingkey
• At least one of the artifact resolution endpoint uses SOAP

The signing key seems weak. Our metadata contains the key elements:

        <KeyDescriptor>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                         [....]

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?

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:

        <SingleSignOnService
Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"

 Location="https:/IDP_HOST/idp/profile/Shibboleth/SSO" />
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                             Location="
https://IDP_HOST/idp/profile/SAML2/POST/SSO" />
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"

 Location="https:/IDP_HOST/idp/profile/SAML2/POST-SimpleSign/SSO" />
        <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
                             Location="
https://IDP_HOST/idp/profile/SAML2/Redirect/SSO" />

On Tue, Jan 10, 2023 at 4:13 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> >  What we have seen is when they try to import our metadata, they get some
> > "Invalid static metadata" error, but unfortunately nothing more specific
> than
> > that.
>
> Presumably then you'd have to start munging the metadata to remove
> extensions and unusual content to strip it down to bare bones.
>
> 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.
>
> -- Scott
>
>
>
>
>

-- 
Baron Fujimoto <baron at hawaii.edu> ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230221/bc591fe9/attachment.htm>