Purpose

This WS is designed to determine available users approvals (scopes) that can be authorized in client from request. Requested scopes should be allowed for user role, client type and additional configurable scopes lists based on persons legal capacity or confidant person relationship status.

Key points

1. This method should be reachable only by the eHealth authorization front-end application.

2. This method is used only for patients users.

3. If not any scope from list can be authorized - empty list is returned.

Specification

Apiary

Validations

Validate token

• Check Authorization header with Bearer token exists

  • in case of error - return 401 ('Authorization header is not set or doesn't contain Bearer token')

• Check that token is valid and not expired

  • in case of error - return 401 ('Invalid access token')

• Check user scopes in order to perform this action (scope = 'app:authorize')

  • in case of invalid scope(s) - return 403 (“Your scope does not allow to access this resource. Missing allowances: app:authorize”)

• Check that token contains person_id

  • in case of error - return 401 ('Invalid access token')

Validate client

• Check client_id field exists in request and is not empty

  • in case of error - return 422 ('required property client_id was not present')

• Check client exists in mithril database, client table

  • in case of error - return 404 ('Client not found')

• Check client is not blocked (is_blocked <> true)

  • in case of error - return 401 ('Client is blocked')

Validate scope

• Check scope field exists in request

  • in case of error - return 422 ('required property scope was not present')

Check relationship between patient and confidant person

This validation must be done only in case user_id and applicant_user_id are different as it means that it is a part of confidant person process. In such case we must ensure that relationship between both persons exist and is valid

Get person_id and applicant_person_id from token details

Check relationship using Relationship between Confidant Patient and Related Patient validation algorithm and having person_id and applicant_person_id

• If relationship doesn’t exist - return 401 ('Can’t confirm relationship')

Service logic

1. Extract user_id from token. Search for user roles and global user roles in mithril database. Filter $.scope value with scopes for user roles or global roles

   1. if resulted list is empty - return empty scopes list in response

   2. if resulter list is not empty - go to next step

2. Get client type scopes by client_id. Filter $.scope value with scopes for client type

   1. if resulted list is empty - return empty scopes list in response

   2. if resulter list is not empty - go to next step

3. Get applicant_person_id from token details, compare it to person_id from token:

   1. if equal - check whether person corresponds to following rules:

      1. persons age < no_self_registration_age global parameter;

      2. persons age between no_self_registration_age and person_full_legal_capacity_age global parameters and person does not have document with type from PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter;

      3. persons age > person_full_legal_capacity_age global parameter and exists at least one active and approved confidant person relationship for person (using following process https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17415995422 with person_id = person from request - expected :ok, :approved response)

         1. if person does not correspond to rules - return filtered scopes list in response

         2. if person corresponds to rules - filter $.scope value with allowed scopes from PIS_READ_ONLY_SCOPES_ALLOWED config parameter. Return filtered scopes list in response

   2. if not equal - check relationship status between person and confidant person using following process https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17415995422 with person_id = person_id and confidant_person_id = applicant_person_id

      1. if process returns :ok, :approved - return filtered scopes list in response

      2. if process returns :ok, :not_approved - filter $.scope value with allowed scopes from PIS_NOT_VERIFIED_RELATIONSHIP_SCOPES_ALLOWED config parameter. Return filtered scopes list in response

4. Render a response according to specification.