RealMe

RealMe

RealMe Assertion Messaging Test Site

About SAML v2.0 Request

A SAML v2.0 Request is sent from a SAML Service Provider (SP) and initiates a SAML v2.0 response at the MTS IdP.

As the majority of integrations use products or code libraries that comply with the OASIS SAML v2.0 standard, developers should focus on the RealMe requirements that differ in some way from the OASIS Standard or have additional NZ specific constraints.

The following list of the key RealMe SAML message request parameters highlights the ones that are most likely to need close attention. Refer to RealMe request parameters for more detail.

  1. Issuer - identifies which Service Provider has sent the AuthnRequest. This should conform to the recommended RealMe three-part format used for entityID in the metadata.
  2. Format (within NameID policy) - the RealMe assertion service format is "transient", but "unspecified" is also permitted in the request.
  3. RequestedAuthnContextClassRef - this tells the IdP what level of authentication can be used. RealMe uses custom values; for assertion, the value is always: urn:nzl:govt:ict:stds:authn:deployment:GLS:SAML:2.0:ac:classes:ModStrength
  4. AssertionConsumerServiceIndex - this indirectly informs the IdP where to return the AuthnResponse according to the corresponding values in the SAML metadata including the SP endpoint.
  5. RelayState - this optional parameter may be provided for private use by the Service Provider to maintain the session state. It must not exceed 80 bytes in length and should be integrity protected by the Service Provider.

The signature is generated by signing the base64 and URL encoded request combined with the RelayState (if present in the assertion request) and the URL representation of the signature algorithm. A sample SAML v2.0 assertion request is shown below.

You can submit the content of the SAMLRequest here.

Or send a request directly from your browser by appending your SAML Request to the MTS endpoint (as provided in the RealMe assertion service IdP metadata file).

Once your SAML v2.0 assertion request passes successful SAML v2.0 messaging validation, schema validation and signature validation, you are redirected to an outcome page, so that you can initiate a SAML v2.0 response.

If your SAML v2.0 assertion request does not pass validation, the relevant error messages are provided to assist you in resolving the error, so you can try again.