Drive a SAML SSO round-trip against an Identity Provider, in SAML 2.0 or SAML 1.1. Load the IdP's metadata, configure the Service Provider request, generate an SP signing key pair, and send the request over the chosen binding. The IdP's response is captured by the ACS endpoint and shown on the SAML Response page.
The two versions are different protocols, not two spellings of one. SAML 2.0 is SP-initiated: the request is a <samlp:AuthnRequest> document, which can be signed and (here, for inspection) encrypted. SAML 1.1 has no request message at all — its browser profiles are IdP-initiated, and what a service provider actually sends is Shibboleth's urn:mace:shibboleth:1.0:profiles:AuthnRequest: the four query parameters TARGET, shire, providerId and time, with nothing to sign and nothing to encrypt. Every setting below that has no meaning in 1.1 is greyed out and switched off when 1.1 is selected, rather than silently ignored. SAML 1.0 remains reference-only. Keycloak speaks no SAML 1.1; the mock STS does.
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.
