The SP simulator allows you to test a full authentication flow independently, without the need of any integration with an external system. By using this tool you can explore the different options the Connectis Identity Broker offers and examine the messages sent and received to/from the Broker.

Starting an authentication flow

1. Note your tenant's URL, e.g. your-tenant.cib.pre.connectis.com

2. Browse to url-of-your-tenant/sp-simulator, e.g. https://your-tenant.cib.pre.connectis.com/sp-simulator

3. For eHerkenning or eIDAS, fill in an Attribute Consuming Service Index to request the correct service. The indices that can be used are

   1. eHerkenning:

      1. KvK number: 9046

      2. RSIN: 9039

   2. eIDAS:

      1. 1.9 Pseudo eIDAS Inbound (No Polymorphic Encryption): 9083

      2. 1.9 LegalIdentifier eIDAS Inbound (No Polymorphic Encryption): 9084

4. Select the Level of Assurance you minimally require the user to authenticate with. (For the easiest login flow, choose "PasswordProtectedTransport".)

5. Press OK.

6. The simulator will send an authentication request to the Connectis Identity Broker.

In the selection screen, choose an IdP. The available choices are:

1. Connectis Broker 1.11 (Pre-production): for eHerkenning and eIDAS connections.

2. DigiD Simulator: Simulator for DigiD login

3. IDIN Simulator: Simulator for IDIN login

Other options in SP Simulator form

• Force Authentication: This option set the attribute ForceAuthn to true on the SAML AuthnRequest sent to the broker. (Default value: false). This means that the user will always have to login at the IdP, even though they still have an active session.

• Requester name: Defines the attribute “ProviderName” on the SAML AuthnRequest sent to the Broker. This appears on the SAML request and has no functional effect.

• Protocol Binding: Defines the attribute “ProtocolBinding” on the SAML AuthnRequest. If left blank, the Broker will infer the SAML binding used between the different bindings available (ie. POST, Redirect, etc)

• Level of Assurance: The level of assurance the SP will request to the Broker.

Level of assurance (LoA)

You can also select the level of assurance that will be requested to the Broker. By default our broker accepts requests and returns LoAs defined in the SAML 2.0 specification documents (https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf)

In the trial environment are defined the next LoAs:

• urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

• urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

• urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered

• urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract

• urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI

eHerkenning or iDIN don’t use the same LoA names. To handle this situation, the Broker will translate eHerkenning or iDIN level of assurances to SAML level of assurances and vice versa. This behavior is configurable by working with what we call Level of Assurance Contract, but this configuration is not available on the trial.

Receiving an authentication response

Authentication responses are received at the ACS (assertion consumer service) endpoint of the SP simulator. Upon receiving an authentication response, the SP simulator will show (at least) the following information:

• SubjectStatus

• NameID

• LevelOfAssurance of the response

• Saml Message

If the response had some attributes in the AttributeStatement section, you will also see these attributes on the SP response page.

Unexpected results

During the login process, there is always the possibility of ending up in an unexpected state that will result in a “Melding” error. We try to give you the liberty with our simulators to configure every actor involved in a login flow so you can test in real time how the application will behave. Most of the time, an unexpected result will not happen in a production environment unless there is some unexpected behavior on the IdP / SP side.

A clear example of this behavior is:

1. SP requests MobileTwoFactorContract LoA

2. Select DigiD simulator.

3. Select to return PasswordProtectedTransport.

4. Broker fails with melding because the LoA returned by the IdP was insufficient to comply with the SP request.

At the SP simulator ACS endpoint you have the option to login again or logout.

Login Again

This will send you back to the beginning to re configure the SAML authentication request.

Logout

By clicking Start Logout, you can start the logout flow. Here the SP simulator will send to the Broker a SAML Logout Request. In the logout request the NameID will have the value of the previously logged in user’s NameID.