Home Supported Standards Terms & Conditions Privacy Policy Documentation Contact About

← Return to home

Drive a WS-Federation Passive Requestor Profile sign-in against an Identity Provider (e.g. AD FS / Azure AD). Load the IdP FederationMetadata.xml, set the relying-party realm (wtrealm) and return URL (wreply), then send the browser to the IdP with wa=wsignin1.0. The IdP POSTs a wresult (a WS-Trust RequestSecurityTokenResponse carrying a SAML assertion) back to wreply; it is shown on the WS-Federation Response page, where you can validate the token signature and decrypt an encrypted token. The passive-profile sign-in request itself is not signed.

This is the static (backend-less) deployment. There is no API proxy, so metadata must be pasted in (a direct browser fetch is usually blocked by CORS) and the backend routing option is disabled below. There is also no landing endpoint, and the IdP returns the token as an HTTP POST, so the response cannot be captured automatically: build the sign-in request here, complete it in the browser, then paste the returned wresult into the WS-Federation Response page to inspect it. The token is captured, though: the IdP's POST to wreply is answered at the CDN edge by a function that hands the wresult to the WS-Federation Response page, so the full round trip completes here with no server. (The passive profile has no redirect response binding, so unlike SAML there is no other way to do this statically.)

Tip: click a pane's title to collapse/expand it.

IdP Federation Metadata
IdP Configuration
Sign-in Request

Signing uses the relying-party private key below — press Generate Keys if there is none. With signing on and no key the request is built unsigned and the status says so, rather than quietly sending one that only looks signed. The enveloped binding needs an inline wreq to sign, so selecting it turns that on.

Relying-party Key Pair (token decryption)

Register this certificate at the IdP so it can encrypt the issued token to this RP. The private key is reused on the response page to decrypt an EncryptedAssertion/EncryptedData. All signature/encryption algorithm handling is automatic on the returned token; the sign-in request itself is not signed.

Generated Request & Send
Operations History

Chronological history of every attempted call to the IdP from this page — the wsignin1.0 sign-in and the wsignout1.0 sign-out — newest first. Result is one of: Failure, the call never left the browser (no endpoint, no wtrealm, a refused URL scheme); Sent, the browser was handed to the IdP and no answer has come back yet — an entry that stays Sent means the IdP never returned a wresult to this debugger, so check the IdP's own error page; Success, the IdP returned a token (or completed the sign-out). A Sent entry is closed out on the WS-Federation Response page, because in the Passive Requestor Profile that is where the IdP's answer lands. The history is kept in this browser's local storage and survives a reload.