Azure AD B2C SAML

    Monthly Archives: January 2020

    SAML Http Redirect Signature Verification

    Posted on January 3, 2020 by b2cdev

    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

    1. 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.
    2. 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
    3. 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.
    4. 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

    Posted in Uncategorized | Leave a comment |

    Pages

    Archives

    • January 2020
    • October 2019

    Categories

    • Uncategorized (2)

    WordPress

    • Log in
    • WordPress

    Subscribe

    • Entries (RSS)
    • Comments (RSS)

    Pages

    Archives

    • January 2020
    • October 2019

    Categories

    • Uncategorized (2)

    WordPress

    • Log in
    • WordPress

    CyberChimps Pro Premium WordPress Theme

    © Azure AD B2C SAML