user-management.md

# User management

## Sign up

There are two steps to create an account on data.grandlyon.com.

First of all the user must go to the sign up page accessible from the login page and fill the form. A few information are required such as the firstname, the lastname and the email. A password also has to be entered. It must:

* have at least 6 characters
* contain at least one special character
* contain at least one uppercased character
* contain at least one lowercased character
* contain at least one number

Passwords are always encrypted with a public key retrieved from the [legacy auth middleware](../../middlewares/legacy-auth.md) before they are sent accross the network. Only the legacy auth middleware knows the private key that allow the decryption of the password.

Before being able to submit the form, the user has to accept the general terms of use and the processing of its information.

When the form is submitted, the account is not directly created. In fact, a request is made to the [legacy auth middleware](../../middlewares/legacy-auth.md). The service stores temporarily the user account information in a Redis database and send an email to the user's email address through the [email service](../../services/mailer.md). The purpose of this email is to confirm the validity of the user's email address. Indeed the email contains a unique link which expires after 24h.

The link is actually a link to the login page of our application that includes a `token` query param. When the `LoginComponent` of the Angular app detects a `token` param in the url, it sends an HTTP request to the [legacy auth middleware](../../middlewares/legacy-auth.md) including the token. If the token is still valid the user account associated with this token is created in the real user database of the [legacy auth service](../../core/legacy-auth.md).

For more information about this process read [this](../../../miscellaneous/authentication&authorization.md) section of the documentation.

## Sign in

Obviously, on the sign in page the user can enter its credentials in order to authenticate himself/herself. For more details refer to [this](../../../miscellaneous/authentication&authorization.md) section of the documentation.

A checkbox on the left of the password input allow one to display the content of the input.

## Password forgotten

A user that forgets its password can click the `Password forgotten` button from the sign in page. The application will then display a second form asking the user to enter its email address. When the form is submitted, the password is encrypted with the public key retrieved from the [legacy auth middleware](../../middlewares/legacy-auth.md). Then just as in the sign up process the app sends a request to the middleware that in its turn sends an email to the user address ,through the [mailer](../../services/mailer.md), containing a link valid for 24 hours.

The link sends the user on the page dedicated to the reset of the password. This page first verifies that a token is indeed present in the query param of the current url. It also checks with the [legacy auth middleware](../../middlewares/legacy-auth.md) if the token is still valid. In the failing case a message ask the user to restart the password reset process from the beginning. When the token is valid, the user is asked to enter a new password. Finally the application sends the request to the middleware along with the token from the query param. The middleware checks again the validity of the token and then make an HTTP call to the `Legacy auth` service in order to apply the new password to the email associated to the user account.

Here's a diagram that sums this up.

```plantuml

!define BLACK   #333745
!define RED     #d5232a
!define GREEN   #37A77C

' Base Setting
skinparam BackgroundColor transparent

skinparam Sequence {
    ArrowThickness 1
    ArrowColor RED
    LifeLineBorderColor GREEN
    ParticipantBorderThickness 1
}
skinparam Participant {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

skinparam note {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

participant "Front" as front
participant "Authentication Service" as auth
participant "Middleware Legacy Auth" as middle
participant "Legacy Auth (Neogeo)" as django
participant "Email Service" as email
participant "Kong" as kong
participant "OIDC Server" as oidc

group Password forgotten
    front -> middle : <b>POST</b> /passwordForgotten
    note over middle: Set token in Redis with ttl 24h.
    middle -> email : <b>POST</b> /email/send (body contains the link to the reset password form)
    middle <-- email : void
    front <-- middle : void
end

group Verify Password reset token validity
    front -> middle : <b>GET</b> /isPasswordResetTokenValid
    note over middle: Look for token in Redis.
    front <-- middle : boolean
end

group Password reset
    front -> middle : <b>GET</b> /publicKey
    front <-- middle : { publicKey }
    front -> middle : <b>PUT</b> /user/resetPassword
    note over middle: Look for token in Redis.
    middle -> django : <b>POST</b> /update_user_password/
    middle <-- django
    note over middle: Delete token from Redis.
    front <-- auth : void
end
```

## Sign out

The sign out button is available in the dropdown menu that can be displayed with a click on the user button of the header of the app.

Cookies are used to store the two authentication pieces and more particularily `HTTP only` cookie to store the JWT. It means the application cannot manipulate this cookie, the only way is to force it's expiration through our backend service. This is why the application makes a call to the [authentication service](../../services/authentication.md) which returns two new cookie with the same keys but with outdated expiration dates. Those cookies will replace the two existing ones in the user's browser, and as they are expired they will be removed and user signed out.

```plantuml

!define BLACK   #333745
!define RED     #d5232a
!define GREEN   #37A77C

' Base Setting
skinparam BackgroundColor transparent

skinparam Sequence {
    ArrowThickness 1
    ArrowColor RED
    LifeLineBorderColor GREEN
    ParticipantBorderThickness 1
}
skinparam Participant {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

skinparam note {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

participant "Front" as front
participant "Authentication Service" as auth

group Logout
    front -> auth : <b>GET</b> /logout
    front <-- auth : [200] + cookies with outdated expiration dates
end
```

## User update

A user can easily update its profil information from the user profil page. He needs to agree to the general term of use and the process of its information before sumitting any changes. To update the profil, the application calls the [authentication service](../../services/authentication.md). In its turn it makes the appropriate request to the [legacy auth middleware](../../middlewares/legacy-auth.md) and then generate a new JWT with the latest user information. Finally the [authentication service](../../services/authentication.md) replies to the application with two cookies to replace the older ones.

Here's in bit more details the different exchanges that take place during the update of the user's profil.

```plantuml

!define BLACK   #333745
!define RED     #d5232a
!define GREEN   #37A77C

' Base Setting
skinparam BackgroundColor transparent

skinparam Sequence {
    ArrowThickness 1
    ArrowColor RED
    LifeLineBorderColor GREEN
    ParticipantBorderThickness 1
}
skinparam Participant {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

skinparam note {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

participant "Front" as front
participant "Authentication Service" as auth
participant "Middleware Legacy Auth" as middle
participant "Legacy Auth (Neogeo)" as django
participant "Kong" as kong


group User update
    front -> auth : <b>PUT</b> /user/update
    auth -> middle : <b>PUT</b> /user/update
    middle -> django : <b>POST</b> /update_user/
    middle <-- django : Ok
    middle -> django : <b>POST</b> /get_user/
    middle <-- django : { userInfo }
    auth <-- middle : { userInfo with encrypted password as authzKey}
    auth -> kong : <b>PUT</b> /consumers/:email
    auth <-- kong : Ok
    auth -> kong : <b>GET or POST</b> /consumers/:email/jwt (POST if no creadetials exist for this user)
    auth <-- kong : { credentials }
    front <-- auth : { token: jwt }
end
```

## Password update

From its profile page a user can access to the password update tab. He/she can change its password by filling the dedicated inputs. However the current password must be reentered.

The password update is done through a call to the [legacy auth middleware](../../middlewares/legacy-auth.md). If the request is successful the app will trigger a new login with the new credentials that will be transparent for the user. Doing so, the user wont be logged out on the next authenticated HTTP call (as the password would be outdated) and wont need to reconnect manualy while he/she just entered in the latter form.

```plantuml

!define BLACK   #333745
!define RED     #d5232a
!define GREEN   #37A77C

' Base Setting
skinparam BackgroundColor transparent

skinparam Sequence {
    ArrowThickness 1
    ArrowColor RED
    LifeLineBorderColor GREEN
    ParticipantBorderThickness 1
}
skinparam Participant {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

skinparam note {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

participant "Front" as front
participant "Authentication Service" as auth
participant "Middleware Legacy Auth" as middle
participant "Legacy Auth (Neogeo)" as django
participant "Email Service" as email
participant "Kong" as kong

group Get Public Key
    front -> middle : <b>GET</b> /publicKey
    front <-- middle : { publicKey }
end

group Password update
    front -> middle : <b>PUT</b> /user/updatePassword
    middle -> django : <b>GET</b> /get_user/
    middle <-- django : Ok
    middle -> django : <b>PUT</b> /update_user_password/
    middle <-- django : Ok
    front <-- middle : void
end

group Legacy login
    front -> auth : <b>POST</b> /login/legacy
    auth -> middle : <b>POST</b> /user/login
    middle -> django : <b>POST</b> /get_user/
    middle <-- django : { userInfo }
    middle --> auth : { userInfo with encrypted password as authzKey}
    auth -> kong : <b>PUT</b> /consumers/:email
    auth <-- kong : Ok
    auth -> kong : <b>GET or POST</b> /consumers/:email/jwt (POST if no creadetials exist for this user)
    auth <-- kong : { credentials }
    front <-- auth : { token: jwt }
end
```

## Account deletion

From its profile page, one can also delete its account. A modal is asking for a confirmation in order to prevent that an unwanted click deletes the user account without any possible rollback.

This diagrams shows the different exchanges made.

```plantuml

!define BLACK   #333745
!define RED     #d5232a
!define GREEN   #37A77C

' Base Setting
skinparam BackgroundColor transparent

skinparam Sequence {
    ArrowThickness 1
    ArrowColor RED
    LifeLineBorderColor GREEN
    ParticipantBorderThickness 1
}
skinparam Participant {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

skinparam note {
    BackgroundColor #FFFFFF
    BorderColor BLACK
    FontColor BLACK
}

participant "Front" as front
participant "Middleware Legacy Auth" as middle
participant "Legacy Auth (Neogeo)" as django

group User account deletion
    front -> middle : <b>DELETE</b> /user
    middle -> django : <b>POST</b> /delete_user/
    middle <-- django : Ok
    front <-- middle : void
end
```

## User accesses

This page is composed of two tabs:

* one for the restricted access datasets that the user can access
* one for the restricted access datasets that the user can require access to

In both tab, a dataset's name is an internal link that redirects to the corresponding dataset detail page.

### Request access to a new dataset

Each dataset can have many different available services (WMS, WFS...). The user can request access to all the services for this particular dataset or chose to require access only to the services he/she is interested in.

<!-- TO BE COMPLETED -->
<!-- At first the user is granted a one month access. He/she will receive an email asking for more details about the use he/she will do of the services.  -->

Once a service has been requested it will disapear from the available services list. Instead it will appear in the user accesses tab.

### User accesses management

A user access state can have three different values:

* Pending, the user request hasn't been accepted yet
* Ok, the user request has been accepted and the expiration date has been reached
* Expired, the expiration date has been reached

From this table, one can remove its access to a service but can also renew it if it has expired or if it is soon to be expired. The user and the dedicated team on our side will receive an email acknowledging the request. However, there is currently no way in the backend to change the state of the service to `renewal request pending` so there will be no change in the application until the request has been accepted.