Обсуждение:Верхнеуровневая архитектура

Версия 1

Создал юз-кейс для централизованного варианта (когда все данные проходят через управляющую подсистему. Схему залил целиком ту, что мы нарисовали (с модификациями для читабельности). Ниже мои мысли по этой схеме.

По HTTPS.

Пользователь должен проходить аутентификацию и авторизацию на сервере - вводить логин/пароль. Процедуру авторизации/аутентификации придется все-равно писать самостоятельно. Предполагалось использовать следующий протокол.

Регистрация:

1. Пользователь задает логин
2. Пользователь задает ключ аутентификации $K_A$ (либо вычисляет его как хеш от пароля).
3. Пользователь, используя известный открытый ключ сервера, шифрует логин/ключ и передает их серверу, сервер их сохраняет.

Аутентификация:

1. Клиент генерирует случайную байтовую последовательность $CRAND$.
2. Клиент вычисляет шифр $CENC_1=E_{K_A}(CRAND)$.
3. Клиент в открытом виде посылает $CRAND$ и свой логин на сервер.
4. Сервер, после получения запроса с $CRAND$ и логином от клиента, вычисляет $SENC_1=E_{K_A}(CRAND)$.
5. Сервер генерирует случайное $SRAND$
6. Сервер вычисляет $SENC_2=E_{K_A}(SRAND)$.
7. Сервер посылает $SRAND$ и $SENC_1$ клиенту по открытому каналу.
8. Клиент сравнивает $CENC_1$ и полученный $SENC_1$, и, если имеется равенство, аутентификация сервера пройдена.
9. Клиент вычисляет $CENC_2=E_{K_A}(SRAND)$.
10. Клиент посылает $CENC_2$ в открытом виде на сервер.
11. Сервер проверяет равенство $CENC_2$ и $SENC_2$ и, если равенство истинно, аутентификация клиента пройдена.

При таком протоколе мы проводим аутентификацию и клиента, и сервера за раз. Алгоритмы шифрования при аутентификации используются симметричные, следовательно имеется большая производительность, по сравнению с асимметричными шифрами SSL. Единственное место, где возможно проведение атаки "человек-в-середине" и подмена сервера - регистрация, а именно не подтверждается подлинность открытого ключа сервера.

Имеет ли смысл использовать SSL и HTTPS?

--Андрей Чусов (обсуждение) 18:35, 7 июля 2015 (UTC)

По СУБД

Готовым (и поставляемым) продуктом будет сервер со всеми сервисными подсистемами. Таким образом мы будет поставлять и СУБД - MariaDB. Вопрос с лицензированием - не придется ли открывать код?

Еще раз: назначение СУБД2 - бэкапы? Кто будет удалять ненужные проекты, если они хранятся на сервере?

--Андрей Чусов (обсуждение) 18:35, 7 июля 2015 (UTC)

Use-case

Часть юз-кейса с назначением физических параметров модели выглядит немного избыточной. Предлагаю:

1. Пользователь обращается к управляющей подсистеме с запросом на ассоциацию данных из СУБД1 с компонентами геометрической модели для выбранной предметной области.
2. Управляющая система считывает идентификаторы данных с СУБД2 и ассоциирует их с компонентами модели
3. Управляющая подсистема делегирует запрос подсистеме предметной области.
4. Подсистема предметной области считывает данные из СУБД напрямую по адресу, предоставленному управляющей подсистемой.
5. Подсистема предметной области задает ассоциацию данных с компонентами геометрической модели.

--Андрей Чусов (обсуждение) 18:35, 7 июля 2015 (UTC)