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.
Note your tenant's URL, e.g. your-tenant.cib.pre.connectis.com
Browse to url-of-your-tenant/sp-simulator, e.g. https://your-tenant.cib.pre.connectis.com/sp-simulator
For eHerkenning or eIDAS, fill in an Attribute Consuming Service Index to request the correct service. The indices that can be used are
eHerkenning:
KvK number: 9046
RSIN: 9039
eIDAS:
1.9 Pseudo eIDAS Inbound (No Polymorphic Encryption): 9083
1.9 LegalIdentifier eIDAS Inbound (No Polymorphic Encryption): 9084
Select the Level of Assurance you minimally require the user to authenticate with. (For the easiest login flow, choose "PasswordProtectedTransport".)
Press OK.
The simulator will send an authentication request to the Connectis Identity Broker.
In the selection screen, choose an IdP. The available choices are:
Connectis Broker 1.11 (Pre-production): for eHerkenning and eIDAS connections.
DigiD Simulator: Simulator for DigiD login
IDIN Simulator: Simulator for IDIN login
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.
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.
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.
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:
SP requests MobileTwoFactorContract LoA
Select DigiD simulator.
Select to return PasswordProtectedTransport.
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.
This will send you back to the beginning to re configure the SAML authentication request.
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.