Hyperledger Composer с пользовательской реализацией обратной связи - PullRequest
Новая
       10

Hyperledger Composer с пользовательской реализацией обратной связи

0 голосов
/ 28 августа 2018

Я хотел бы создать пользовательский петлевой сервер для обработки карт композитора Hyperledger, связанных с пользователями.

В сценарии, который я хочу создать, есть разные пользователи, которые могут выполнять транзакции в блокчейне.

Пользователь должен иметь возможность войти на веб-портал и отправить транзакцию.

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

Как только пользователь вошел в систему, сервер должен распознать его и выбрать карту-корреспондент, связанную с этим конкретным пользователем.

enter image description here

Кто-нибудь знает, какой может быть лучший подход для реализации этого?

1 Ответ

0 голосов
/ 28 августа 2018

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

  2. Вы должны создать участников в Composer (класс (ы), для которых определены файлы модели) в бизнес-сети и выдавать удостоверения через Composer (сопоставленный с участником выше) - или даже из вашего CA сервер, как администратор (например, пользователь проходит через процесс регистрации пользователя какого-либо приложения, затем активирует учетную запись, свою идентификацию блокчейна, через ссылку на свой идентификатор электронной почты и т. д. и т. д. или в соответствии с требованиями). Ваш идентификатор Composer (в бизнес-сети) может каким-то образом отображаться на идентификатор пользователя веб-портала (то есть: хотите ли вы, чтобы он был прямым или косвенным, вы будете лучше знать свою архитектуру безопасности).

  3. В этом стеке есть ответы на некоторые вопросы, о которых вы спрашиваете -> Аутентификация пользователя веб-приложения Hyperledger Composer

  4. Очевидно, что вы будете использовать стратегию аутентификации для аутентификации пользователей вашего веб-приложения - например, если ваше приложение использует API REST Composer для взаимодействия с бизнес-сетью в блокчейне. Смотрите пример этого руководства Google OAUTH2 (на основе аутентификации клиента) -> https://hyperledger.github.io/composer/latest/tutorials/google_oauth2_rest.

...