Azure B2c Signature verification for SAML Http redirect messages. B2c implements http redirect parsing as per the saml binding specifications.
Following are the rules used while processing the signature
- The signature algorithm identifier MUST be included as an additional query string parameter, named SigAlg. The value of this parameter MUST be a URI that identifies the algorithm used to sign the URL-encoded SAML protocol message, specified according to [XMLSig] or whatever specification governs the algorithm.
- To construct the signature, a string consisting of the concatenation of the RelayState (if present), SigAlg, and SAMLRequest (or SAMLResponse) query string parameters (each one URLencoded) is constructed in one of the following ways (ordered as below):
- SAMLRequest=value&RelayState=value&SigAlg=value
- SAMLResponse=value&RelayState=value&SigAlg=value
- The signature value MUST be encoded using the base64 encoding (see RFC 2045 [RFC2045]) with any whitespace removed, and included as a query string parameter named Signature. Note that some characters in the base64-encoded signature value may themselves require URL-encoding before being added.
- The following signature algorithms (see [XMLSig]) and their URI representations MUST be supported with this encoding mechanism:
- DSAwithSHA1 – http://www.w3.org/2000/09/xmldsig#dsa-sha1
- RSAwithSHA1 – http://www.w3.org/2000/09/xmldsig#rsa-sha1
Note that when verifying signatures, the order of the query string parameters on the resulting URL to be verified is not prescribed by this binding. The parameters may appear in any order. Before verifying a signature, if any, the relying party MUST ensure that the parameter values to be verified are ordered as required by the signing rules above.
Further, note that URL-encoding is not canonical; that is, there are multiple legal encodings for a given value. The relying party MUST therefore perform the verification step using the original URL-encoded values it received on the query string. It is not sufficient to re-encode the parameters after they have been processed by software because the resulting encoding may not match the signer’s encoding. Finally, note that if there is no RelayState value, the entire parameter should be omitted from the signature computation (and not included as an empty parameter name).
An implementation of above algorithm by Azure B2C can be found at: https://github.com/avdate-git/SamlB2cSignature