Drive a SAML 2.0 SP-initiated SSO round-trip against an Identity Provider. Load the IdP's metadata, configure the Service Provider request, generate an SP signing key pair, and send a digitally signed AuthnRequest. The IdP's response is captured by the ACS endpoint and shown on the SAML Response page. Note: SAML 1.0/1.1 are provided for reference only — they are IdP-initiated with no signed SP request and are not accepted by SAML 2.0 IdPs such as Keycloak.
This is the static (backend-less) deployment. Loading IdP metadata, building/signing the AuthnRequest, and capturing the IdP's response all run entirely in the browser. The Assertion Consumer Service is answered at the CDN edge by a function that hands the response to the SAML Response page, so the request asks for the HTTP-POST binding exactly as it would with a backend — which is what the profile requires, and what lets an encrypted assertion work here (ciphertext does not compress, so a redirect-bound encrypted response runs into URL-length limits). With no ACS server to receive a POST, the request asks the IdP to return its response over the HTTP-Redirect binding, which SAML Response reads from the URL. Note that saml-profiles-2.0-os §4.1.2 says the Redirect binding MUST NOT be used for the response, "as the response will typically exceed the URL length permitted by most user agents" — it works here for a modest assertion, it needs the IdP to permit it, and a large or encrypted assertion may not fit browser/CDN URL-length limits. The HTTP-Artifact binding needs the server-side SOAP back-channel and is unavailable here.
Tip: click a pane's title to collapse/expand it.
