Мета

Цей WS призначений для авторизації скоупів користувачів. Запитані скоупи мають бути дозволені для ролі користувача, типу клієнта та скоупів посередника клієнтів.

Ключові положення

1. Цей метод має бути доступним лише для фронт-енд додатку авторизації в eHealth.

2. Цей спосіб ідемпотентний.

3. Після створення апрувалу користувач має бути перенаправлений на redirect_url з code квері параметром.

Специфікація

Apiary

Валідації

Валідувати токен

• Перевірити хедер авторизації, що він містить Bearer токену

  • в разі помилки - отримати 401 ('Authorization header is not set or doesn't contain Bearer token')

• Перевірити, що токен дійсний і валідний

  • в разі помилки - отримати 401 ('Invalid access token')

Перевірити користувача

• Отримати user_id з токену

• Перевірити, що користувач не заблокований (is_blocked <> true)

  • в разі помилки - повернути 401

• Перевірити скоупи користувача на можливість виконання даної дії (scope = 'app:authorize')

  • в разі невалідних скоупів - повернути 403 (“Your scope does not allow to access this resource. Missing allowances: app:authorize”)

Перевірити клієнта

• Перевірити, що поле client_id присутнє в запиті і не пусте

  • в разі помилки - повернути 422 ('can't be blank')

• Перевірити, що клієнт не заблокований (is_blocked <> true)

  • в разі помилки - повернути 401 ('Client is blocked)

Перевірити uri для перенаправлення

• Перевірити, що поле redirect_uri вказано в запиті і не пусте

  • в разі помилки - повернути 422 ('can't be blank')

• Перевірити, що вказане uri належить клієнту по базі даних mithril, таблиця connections з використанням client_id

  • в разі помилки - повернути 401 ('The redirection URI provided does not match a pre-registered value.')

Перевірити скоупи

• Перевірити, що поле scope вказані в запиті і не пусті

  • в разі помилки - повернути 422 ('Requested scope is empty. Scope not passed or user has no roles or global roles.')

• Отримати user_id з токену. Здійснити пошук ролів користувача та глобальних ролів користувача в базі даних mithril. Перевірити, що значення в полі scope існує в скоупах ролі користувача і глобальних ролях

  • в разі помилки - повернути 401 ('Scope is not allowed by user role.')

• Отримати скоупи типу клієнта по client_id. Перевірити, що значення в полі scope існує в скоупах типу клієнта

  • в разі помилки - повернути 401 ('Scope is not allowed by client type.')

Перевірити взаємозв'язок між пацієнтом та довіреною особою (опційно)

Дана перевірка має здійснюватись тільки в разі, якщо user_id та applicant_user_id різні, що означає, що це частина процесу по довіреним особам. В даному випадку ми маємо переконатись, що взаємозв'язок між обома персонами існує і є дійсним.

Отримати person_id та applicant_person_id з деталей по токену.

Перевірити взаємозв'язок, використовуючи Relationship between Confidant Patient and Related Patient validation algorithm та за наявності person_id та applicant_person_id

1. Якщо взаємозв'язок не існує - повернути 401 ('Can’t confirm relationship')

Сервісна логіка

1. Визначити скоупи для погодження

   1. якщо взаємозв'язок підтверджено - обробити з запитаними скоупами

   2. якщо взаємозв'язок існує і не є підтвердженим - профільтрувати запитані скоупи у відповідності до погоджених скоупів (env PIS_NOT_VERIFIED_RELATIONSHIP_SCOPES_ALLOWED). Тож тільки ті скоупи, що є в списку дозволених

2. Погодити запитані скоупи для client_id та user_id (перелік скоупів вказано в п.1)

3. Додати або оновити перелік погоджених скоупів для користувача та клієнта в базі даних mithril, таблиця apps, встановити:

   1. id = автогенерований uuid (для нового запису)

   2. scope = scope

   3. user_id = user_id

   4. client_id = client_id

   5. applicant_user_id = значення з details.applicant_user_id з хедеру токену на авторизації, якщо існує, в іншому випадку user_id

   6. inserted_at = now() (для нового запису)

   7. updated_at = now()

4. Згенерувати токен ‘authorization code’, зберегти токен до бази даних mithril, таблиця tokens, встановити:

   1. id = uuid токену

   2. name = 'authorization_code'

   3. value = хеш токену

   4. expires_at = дата та час закінчення строку дії токену в форматі unix-time

   5. details = додаткова інформація по токену (scope_request, client_id, grant_type, redirect_uri, applicant_user_id, applicant_person_id, app_id)

      1. applicant_user_id = значення з details.applicant_user_id з хедеру токену на авторизації (if exists)

      2. applicant_person_id = значення з details.applicant_person_id з хедеру токену на авторизації (if exists)

      3. app_id = uuid дозволу між user_id, applicant_user_id та client

   6. user_id = user_id

   7. inserted_at = now()

   8. updated_at = now()

5. Згенерувати термінові дані – додати значення авторизаційного коду токену до redirect_uri.

6. Відобразити відповідь у відповідності до специфікації.