The SAML Request tab allows testing authentication via SAML requests
Authentication with authentication mean allows you to choose up to seven different authentication means
Authentication with LoAallows you to authenticate with a certain level of access. Each level will provide one or more authentication means
Binding methods allows you to choose how SAML Request will be performed
Single sign-on can be tested with this demo tool by logging in once with the eID authentication method. Any following authentication (by returning to the SAML Request tab) will no longer show the login button
Press the submit button to perform the request. You will be redirected to the SAML Response tab.
SAML Response show the response of the SAML Request
SAML info gives more information about the SAML response that we received from the FAS.
Attributes show all attributes that were included in the SAML response. These attributes cannot be chosen during the demo but are decided during the onboarding of the demo.
OpenID Request is to send an OpenId connect request
Authentication with authentication mean allows you to choose up to seven different authentication means
Authentication with LoA allows you to authenticate with a certain level of access. Each level will provide one or more authentication means
Not choosing an authentication mean or level will authenticate you with level 500
The scopes options allows you to choose different scope values that will be send along with the request. Different scopes will provide different result in the response page. The openid scope is mandatory and cannot be unchecked.
The authorization type will define which client is used to make the request. This will be either the "OpenIDDemoPOC"client which uses basic client id and secret authentication, or the "OpenIDPrivateKeyJWT" client which uses the more advanced private key jwt token.
Press the submit button to perform the request and redirect to the response tab
The Authorization Code Request shows the request that was made by the toolbox to obtain the authorization code. The parameters of the request should reflect the options given in the request tab
The Access Token Request shows the request that was made to obtain the access token. The authorization code above will be one of the parameters of the request.
The Refresh Access token button can be used to request a new access_token using the refresh token instead of the authorization code. This will also be reflected in the access token request.
The Headers will show all headers that are send along the request
The Access token response contains the access token, a refresh token and an id token. The id token will be used to ...
The id token is a JWT token. This token consists of three different parts. All parts can be found decoded in their respective tab in the Decoded ID Token section.
The id token will be validated using the public key of the FAS. If the token cannot be validated an error message will appear.
The End User Info shows a request that was made the retrieve additional user info (not in the id_token) using the access_token.
The User info response is a JWT token. This token consists of three different parts. All parts can be found decoded in their respective tab in the User info Response section
The Authorization Code Request shows the request that was made by the sandbox to obtain the authorization code. The parameters of the request should reflect the options given in the request tab
The Access Token Request shows the request that was made to obtain the access token. The authorization code above will be one of the parameters of the request.
The Refresh Access token button can be used to request a new access_token using the refresh token instead of the authorization code. This will also be reflected in the access token request.
Another parameter to the Access Token Request is the client_assertion token. This is a JWT token. The token consists of three parts. This token will be validated by openam using an endpoint that provides your public key (or with a public key given to the system administrator)
kid = key id (the identifier of your public key)
alg = The algorithm used for the signature
jti = A unique jwt token identifier
iat = The creation time of the token (in milliseconds)
iss = The issuer of the token (the client id)
aud = The audience of the token. (The url of the access_token endpoint)
exp = The expiration time of the token (in milliseconds)
The Access token response contains the access token, a refresh token and an id token. The id token will be used to ...
The id token is a JWT token. This token consists of three different parts. All parts can be found decoded in their respective tab in the Decoded ID Token section.
The id token will be validated using the public key of the FAS. If the token cannot be validated an error message will appear.
The End User Info shows the request that was made to retrieve additional user info (not in the id_token) using the access_token.
The User info response is a JWT token. This token consists of three different parts. All parts can be found decoded in their respective tab in the User info Response section
A list of external demo tools is shown. Clicking a button will redirect the user to the corresponding website. These tools can be used to test the inbound eIDAS flows.
If the button is grayed out, it means that we don not have the information about the tool of that country (yet).
The logging tab shows all SAML requests
The entity id must be unique for each relying party. The provided button will check whether the chosen name already exists. The form will not be valid until the entity id has been checked.
If the SAML authentications have to be signed, the Signature Certificate field appears. This field must be in the X.509 format and will be validated.
At least one of the logout service urls has to be filled in. If a binding is used both fields (location and response location must be filled in). URLs will be validated.
At least one of the assertion consumer URLs must be filled in. URLs will be validated.
The validate button will validate the entire form (the certificate, if applicable, and the URLs). The form cannot be submitted before it has been validated. NOTE: URLs will only be validated syntactically. This means that we do not check if the URLs point to an actual (and correct) endpoint.
The submit button will generate the XML based on the given fields. The entity id must first be checked for availability and the form must be validated.
FOD Beleid en Ondersteuning Simon Bolivarlaan 30 WTC III 1000 Brussel info@bosa.fgov.be +32 (0)2 740 74 74, van maandag tot vrijdag van 8u tot 17u