Versions Compared

Old Version 6

changes.mady.by.user Rami Sellami

Saved on

compared with

New Version 7

changes.mady.by.user Rami Sellami

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Used documentation

Cookbook/ materialsVersionLocation
Identity & Authorization Management (I.AM) - Overview1.0https://www.ehealth.fgov.be/ehealthplatform/file/view/c87f7d093e56ff1054c73d6aae09e0bb?filename=ehealth_i.am_-_overv
Identity & Authorization Management (I.AM) - Identity Provider (IDP)1.0https://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

FlowSpecification


Use case ID

ATH-UC-06-BF

Use case name

Authentication using itsme

Actors

  • Citizen

  • Healthcare giver
  • Representative of an institution

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

  • The citizen has not an account

  • The citizen has:

    • a phone number

    • an account in itsme

    • a smartphone with the application itsme

    • a five secure code to confirm the operation on itsme

Post-Conditions

  • The user is authenticated

  • The user has access to the services of the mobile application

Steps (basic flow)

0

The user accesses to the WebSSO application interface to authenticate him/herself

1

The user chooses to connect via itsme 


2The user enters his/her phone number recognized by itsme

3The user connects to the itsme application and confirms the operation

4The user sends his/her credentials

5

The application sends an access request to the SP

6

The SP sends an authentication request to the IDP


7

The IDP checks the identity of the user with the AA 


8

The IDP sends a response message to the SP to inform it that the user is identified


9

The SP returns a response message to the application to enable the authentication


10

The user is authenticated and can use the the services of the mobile application

Exceptions (exception flows)

  • The phone number of the user is not recognized by itsme

  • The creation is aborted (e.g. loss of connection, the session is expired)

Frequency

  • Every time the user needs to authenticate to the mobile application


Alternative flow 1

Specification

Use case ID

ATH-UC-06-AF-01

Use case name

First authentication using an eID card

Actors

  • Citizen

  • Healthcare giver

  • Representative of an institution

Short Description

Depending on the profile of the actor, this alternative flow will be instantiated by one of the four use cases dedicated to the creation of a new account (refer to the basic flows): ATH-UC-01, ATH-UC-02, ATH-UC-03, ATH-UC-04.

Priority

1 (High)

Must have: The system must implement this goal/ assumption to be accepted.

Pre-Conditions

  • The user has not an account

  • The user has:

    • an e-mail address

    • an eID card

    • a code PIN of his/her eID card

    • a wireless card reader

Post-Conditions

  • The user has an account

  • The user knows his credentials

  • The user is authenticated

  • The user has access to the services of the mobile application

Steps

For more details and depending on the type of the actor, see:

Exceptions (exception flows)

  • The citizen made an error when editing his/her credentials

  • The PIN of the eID card is not correct

  • The creation is aborted (e.g. loss of connection)

Frequency

  • Every time the user wants to authenticate him/herself and he/she does not have an account.


Exception flow 1

Specification

Use case ID

ATH-UC-06-EF-01

Use case name

The PIN of the eID card is not correct

Actors

  • Citizen

  • Representative of an institution

  • Healthcare giver

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

  • The user has already an account

  • The user has:

    • an eID card

    • a PIN code of his/her eID card

    • a wireless card reader

Post-Conditions

  • The authentication is interrupted

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

  • Every time for a user needs to authenticate him/herself and enter a wrong PIN code

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

  • Citizen

  • Representative of an institution

  • Healthcare giver

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

  • The user has already an account

  • The user has:

    • an eID card

    • a PIN code of his/her eID card

    • a wireless card reader

Post-Conditions

  • The authentication is interrupted

Steps (basic flow)



Frequency

  • Every time for a user needs to authenticate him/herself and loses the connection