SP unsigned requests with AuthnRequestsSigned="true"

[IAM David Bantz]

Scott, you may have been eavesdropping on my phone call with this service
provider.
As an IdP operator I share your frustration, and I'm doubling down because
in my experience it's getting worse not better, which doesn't bode well.

I posted this query here because these folks insist that other IdPs
including at least one InCommon IdP is working with their configuration and
metadata that:
- includes a digital signature of the metadata in the file, which might add
some confidence in the integrity of the metadata if it weren't that the
certificate to validate the signature is also just part of the same file
("if you don't trust the top part of this file, you can validate it with
another part of the same file - isn't that convenient?")
- redirects the user's browser to the published POST endpoint of the IdP;
they seemed put out that I asked them to redirect to the redirect endpoint.
- does not sign the request despite asserting in their metadata that
requests will be signed; they cannot fathom why our IdP refuses the request
in that case
- has an enitityID like "urn:67dd80b***10e971cd29:***astage" which I'm
pretty sure is not a "real" urn / uri\

Apart from the silly waste of time and resources to cobble together a
working integration, why on earth should my institution be trusting this
service to manage sensitive institutional data?

Why are we in this mess?

On Fri, Jul 18, 2025 at 1:47 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> When various folks tell me the standard is "vague" and I react somewhat
> aggressively, this is why.
>
> Quoting:
>
> "However, an identity provider that receives an unsigned
> <samlp:AuthnRequest> message from a service provider whose metadata
> contains this attribute with a value of true MUST return a SAML error
> response and MUST NOT fulfill the request."
>
> Is that somehow unclear?
>
> -- Scott
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250721/8933a7cc/attachment.htm>