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

Introduction

Security Assertion markup Language (SAML) is developed by OASIS (Organization for the Advancement of Structured Information Standards) in early 2000, SAML is an XML-based framework. SAML enables different organizations (with different security domains) to securely exchange authentication and authorization information.  

There three main roles in this communication:

• End User/ Principal

A principal is an entity that needs to be authenticated. It is also referred to as a security principal. Principals can be individual people, computers, services, computational entities such as processes and threads, or any group of such things

• Service Provider (SP)/Relaying Party (RP)

A service provider is a system entity that receives and accepts authentication information.

• Identity Provider (IdP)/ Asserting Party

An identity provider (IdP) is a system entity that creates, maintains, and manages identity information for end users/principals. while providing authentication services to service provider applications within a federation or distributed network. An identity provider offers authentication as a service.

SAML Technical Specification

SAML consists of building-block components that primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship. The core SAML specification defines the structure and content of both assertions and protocol messages used to transfer this information.

Following Figure illustrates the relationship between these basic SAML concepts.

 Basic SAML Concepts

Saml Assertions

SAML assertions carry statements about a principal that an asserting party claims to be true. Assertions are usually created by an asserting party based on a request of some sort from a relying party, although under certain circumstances, the assertions can be delivered to a relying party in an unsolicited manner.

Saml protocol

SAML protocol messages are used to make the SAML-defined requests and return appropriate responses. The structure and contents of these messages are defined by the SAML-defined protocol XML schema.

Saml Bindings

The means by which lower-level communication or messaging protocols (such as HTTP or SOAP) are used to transport SAML protocol messages between participants is defined by the SAML bindings.

Saml Profiles

Next, SAML profiles are defined to satisfy a particular business use case, for example the Web Browser SSO profile. Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings in order to solve the business use case in an interoperable fashion.

Metadata:

Metadata defines a way to express and share configuration information between two communicating providers. For instance, an entity’s support for given SAML bindings, identifier information, and PKI information can be defined. Metadata is defined by an XML schema.

Authentication Context:

Authentication Context permits the augmentation of Assertions with additional information pertaining to the authentication of the principal at the identity provider. For instance, details of multi-factor authentication can be included.

Azure B2C and Saml

Azure B2c is an identity management service that enables developers to customize and control how customers interact with an application.

Azure B2c acts as an IDP for any SP communicating with it and it acts as an SP when it communicates with IDP’s like Salesforce, ADFS etc. In diagram below, various combinations of protocol support are possible.

On Service provider facing end Azure B2c acts as an IDP and can communicate with an OpenId/OAuth or SAML SP.

On IDP facing end, B2c acts as an SP and can communicate with an IDP configured in OAuth/OpenId or Saml configuration.

We will now enumerate what part of Saml technical specifications are supported by Azure B2c.

B2c and Saml profiles

Following two profiles are supported by Azure B2c.

Web Browser SSO Profile:

Defines a mechanism for single sign-on by unmodified web browsers to multiple service providers using the Authentication Request protocol in combination with the HTTP Redirect, HTTP POST, and Artifact bindings.

Single Logout Profile:

A profile of the SAML Single Logout protocol is defined. Defines how SOAP, HTTP Redirect, HTTP POST, and HTTP Artifact bindings may be used.

Profiles not supported

Following profiles are not supported by B2c

1. Enhanced Client and Proxy (ECP) Profile:
2. Identity Provider Discovery Profile
3. Name Identifier Management Profile
4. Artifact Resolution Profile:
5. Assertion Query/Request Profile
6. Name Identifier Mapping Profile

Discussion about above profiles, is out of scope for this document.

B2c and Saml Protocols

Authentication Request Protocol:

Defines a protocol by which a service provider or principal can request assertions from an identity provider tailored to the requirements of a particular SAML profile, for example the Web Browser SSO Profile

Single Logout Protocol:

 Defines a request that allows near-simultaneous logout of all sessions associated by a principal.

Protocols Not supported:

1. Assertion Query and Request Protocol:
2. Artifact Resolution Protocol:
3. Name Identifier Management Protocol
4. Name Identifier Mapping Protocol

B2c and Saml Bindings

HTTP Redirect Binding

Defines how SAML protocol messages can be transported using HTTP redirect messages

HTTP POST Binding:

Defines how SAML protocol messages can be transported within the base64-encoded content of an HTML form control.

Protocols not supported

1. SAML SOAP Binding
2. Reverse SOAP (PAOS) Binding
3. HTTP Artifact Binding:
4. SAML URI Binding

B2c and Saml assertions 

There are 3 types of assertion statements

1. Authentication statements
2. Attribute statements
3. Authorization decision statements

Saml assertions are encyclopedia of specifications of which B2c currently only supports checks for expiry, signature validation, audience and encryption.

---