Acronyms
| Acronyms | Meaning |
|---|---|
| FAS | Federal Authentication Service (aka CSAM) |
Used documentation
| Cookbook/ materials | Version | Location |
|---|---|---|
| Identity & Authorization Management (I.AM) - Overview | 1.0 | https://www.ehealth.fgov.be/ehealthplatform/file/view/c87f7d093e56ff1054c73d6aae09e0bb?filename=ehealth_i.am_-_overv |
| Identity & Authorization Management (I.AM) - Identity Provider (IDP) | 1.0 | https://www.ehealth.fgov.be/ehealthplatform/fr/data/file/view/d43784683d86392e68f1a95b860f721170f30c7b?name=ehealth_i.am_-_idp_v1.0.pdf |
| CSAM Youtube channel | - | https://www.youtube.com/channel/UCzMGudd9xdMeGjYpbpjsXFw |
General information
In the figure below, we provide an overview about the interaction between the different services of the e-health platform involved in the IAM. It is noteworthy that the presented architecture is dedicated to the WebSSO solution.
Basic flow (EID)
| Flow | Specification | ||
|---|---|---|---|
 | Use case ID | UC-001-EID | |
Use case name | Authentication using an eID card | ||
Actors |
| ||
Short Description | This use case denotes the authentication of a user via an eID card. | ||
| Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | ||
Pre-Conditions |
| ||
Post-Conditions |
| ||
Steps (basic flow) | 0 | The user access to the WebSSO application interface to authenticate him/herself and choose the option eID | |
1 | The user connects using his/her credentials (eID card + PIN) and the card reader | ||
2 | The application sends an access request to the SP | ||
| 3 | The SP sends a request message to the AS to access to the IDP | ||
4 | The AS sends a message to the IDP to identify the non authenticated user | ||
5 | The IDP checks the identity of the user with the AA | ||
6 | The IDP sends a response message to the AA to inform it that the user is identified | ||
| 7 | The AS sends a message with the identify of the user to the SP | ||
8 | The SP returns a response message to the application to enable the authentication | ||
9 | The user is authenticated and can use the the services of the mobile application | ||
Exceptions (exception flows) |
| ||
Frequency |
| ||
Exception flow 1
| Specification | ||
|---|---|---|
Use case ID | UC-001-EID-EF-01 | |
Use case name | The PIN of the eID card is not correct | |
Actors |
| |
Short Description | It denotes the use case when the user tries to authenticate with his/her eID card and fails in entering the PIN. | |
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | |
Pre-Conditions |
| |
Post-Conditions |
| |
Steps (basic flow) | 0 | The user access to the WebSSO application interface to authenticate him/herself and choose the option eID |
1 | The user tries to connect using a wrong PIN code | |
2 | The authentication is interrupted | |
Frequency |
| |
Exception flow 2
| Specification | ||
|---|---|---|
Use case ID | UC-001-EID-EF-02 | |
Use case name | The creation is aborted (e.g. loss of connection, problem with the card reader, the session is expired) | |
Actors |
| |
Short Description | It denotes the exception use case when the user loses the connection and he/she will not be able to finish the authentication. It may happens at any step of the basic and alternative flows. | |
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | |
Pre-Conditions |
| |
Post-Conditions |
| |
Steps (basic flow) | ||
Frequency |
| |
Alternative flow 1 (itsMe):
| Flow | Specification | ||
|---|---|---|---|
| Use case ID | UC-001-ITSME | |
Use case name | Authentication using itsme | ||
Actors |
| ||
Short Description | This use case denotes the authentication of a user via itsme. | ||
1 (High) Must have: The system must implement this goal/ assumption to be accepted. | |||
Pre-Conditions |
| ||
Post-Conditions |
| ||
Steps (basic flow) | 0 | The user accesses to the WebSSO application interface to authenticate him/herself | |
1 | The user chooses to connect via itsme | ||
| 2 | The userenters his/her phone number recognized by itsme | ||
| 3 | The userconnects to the itsme application and confirms the operation | ||
| 4 | The user sends his/her credentials | ||
5 | The application sends an access request to the SP | ||
| 6 | The SP sends a request message to the AS to access to the IDP | ||
7 | The AS sends a message to the IDP to identify the non authenticated user | ||
8 | The IDP checks the identity of the user with the AA | ||
9 | The IDP sends a response message to the AS to inform it that the user is identified | ||
| 10 | The AS sends a message with the identity of the user to the SP | ||
11 | The SP returns a response message to the application to enable the authentication | ||
12 | The user is authenticated and can use the the services of the mobile application | ||
Exceptions (exception flows) |
| ||
Frequency |
| ||
Exception flow 1
| Specification | ||
|---|---|---|
Use case ID | ATH-UC-06-EF-01 | |
Use case name | The user makes an error when editing his/her credentials | |
Actors |
| |
Short Description | This use case represents the situation when the user is trying to connect with the itsme and he/she make an error when entering his/her credentials (e.g. The phone number of the user is not recognized by itsme). This exception flow may be triggered by the basic flow and any alternative one. | |
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | |
Pre-Conditions |
| |
Post-Conditions |
| |
Steps | 0 | The user accesses to the WebSSO application interface to authenticate him/herself |
1 | The user tries to connect to the application via itsme | |
2 | The user makes an error when entering his/her credentials | |
Frequency |
| |
Exception flow 2
| Specification | ||
|---|---|---|
Use case ID | ATH-UC-06-EF-02 | |
Use case name | The creation is aborted (e.g. loss of connection, problem with the wireless card reader, the session is expired) | |
Actors |
| |
Short Description | It denotes the exception use case when the user loses the connection and he/she will not be able to finish the authentication. It may happens at any step of the basic and alternative flows. | |
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | |
Pre-Conditions |
| |
Post-Conditions |
| |
Steps (basic flow) | ||
Frequency |
| |