Как защитить composer-rest-server после создания REST API?

Я настроил composer-rest-server. Я также указал имя пользователя/пароль Fabric при настройке composer-rest-server (WebAppAdmin или admin). Теперь я могу получить доступ к REST API без предоставления каких-либо учетных данных (через почтальона или петлю).

Я хотел бы понять, как мы можем защитить composer-rest-server. Хотя я понял, что мы можем добавить идентификацию участника и выдачи, но не можем соединить логические точки в контексте того, как все будет работать.

  • Как защитить composer-rest-server при доступе к REST API?
  • Когда и как мы собираемся использовать «имя пользователя/секрет», зарегистрированное против любого участника?
  • Когда следует аутентифицировать API-интерфейс composer-rest-server и когда использовать удостоверение участника для доступа к бизнес-сети?

hyperledger-composer
person deepak parmar    schedule 14.06.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

См. документацию по этому вопросу: https://hyperledger.github.io/composer/integrating/enabling-rest-authentication.html

person Simon Stone    schedule 14.06.2017
comment
Спасибо Саймон. Я видел этот документ, но меня немного смущает та его часть, которая касается того, как composer-rest-server будет управлять идентификацией, закрытым ключом, сертификатами и кошельком. У меня есть ясность в отношении того, что мы можем использовать стратегию паспорта по нашему выбору для защиты composer-rest-server, но тогда как rest-server позже будет управлять кошельком? У меня есть следующие вопросы: кто и как администрировать composer-rest-server? Придется ли писать отдельное приложение для администрирования composer-rest-server? - Как мы можем настроить composer-rest-server для хранения разных идентификаторов и кошельков в другом месте? - person deepak parmar; 14.06.2017
comment
Было бы здорово, если бы вы могли поделиться какой-нибудь схемой, если она у вас есть. - person deepak parmar; 14.06.2017
comment
Комментарий от Deepak, который указывает на мой пост Stack Overflow, объясняющий весь процесс аутентификации: stackoverflow.com/questions/43655553/ - person Simon Stone; 20.06.2017