Уникальный идентификатор пользователя в нескольких организациях для ACL на уровне цепочки кодов в Hyperledger Fabric

Question

У меня серьезная проблема с управлением идентификацией на уровне кода цепи, я создаю приложение, в которое люди могут загружать свои документы об образовании и профессиональном опыте, а образовательные институты и предыдущие компании могут одобрить его, у меня есть эта проблема при этом :

1. Человек - универсальный участник, он не зависит от какой-либо организации, я хочу дать ему универсальную идентификацию независимо от организаций и MSPS, потому что он может использовать любую организацию просто для подключения к сети, поскольку он не делает поддерживать любого сверстника. Теперь, поскольку я не полагаюсь на учетные данные MSP в коде цепи, поскольку пользователь может получить доступ из любой организации, как я могу проверить, что это тот же человек, который вызвал функцию. Например, в Etherum мы можем просто использовать msg.sender, так как это адрес пользователя Ethereum, а это универсальный идентификатор.

2. В узле фабрики-ca-client sdk нет функции импорта закрытого ключа. Как человек может импортировать свой старый закрытый ключ, когда он переключает организации или использует одноранговый узел из другой организации?

Пожалуйста, помогите мне понять, как реализовать универсальную идентификацию для участников и аутентификацию на уровне цепочки кодов

Из того, что я понял: MspId + CertId дает вам уникальный идентификатор на уровне цепочки:

1. Что произойдет, если сертификат будет отозван? Если сертификат отозван, то пользователь не может выполнять транзакции в сети, и он никак не может использовать свою предыдущую учетную запись.
2. Может ли пользователь использовать сертификат, выданный из msp org1 через одноранговый узел org2? Например, если ему был выдан сертификат учебного заведения, то позднее он хочет выполнить некоторые операции со стороны своего работодателя.

ОБНОВЛЕНИЕ: Я подумал о решении, может быть, мы могли бы передать дополнительную информацию, т.е. дополнительное подписанное сообщение из личного ключа пользователя и соответствующий открытый ключ, используя этот открытый ключ, я могу написать метод в цепочке кодов, чтобы проверить, что сообщение было подписано, используя соответствующий закрытый ключ, и идентифицировать пользователя. Этот механизм не повлияет на сертификаты, используемые для вызова цепного кода.

Может ли кто-нибудь проверить этот механизм?

Answer 1

Для вашего второго выпуска Node SDK позволяет вам использовать существующие криптографические учетные данные с помощью функции Client.createUser(opts).

Для вашей первой проблемы важно понимать, что базовое управление доступом для Fabric осуществляется на уровне channel с двумя основными разрешениями: ChannelReaders и ChannelWriters, Обычно членство в канале и разрешения находятся на уровне организации.

Допустим, у вас есть 5 организаций (Org1-Org5), работающих с одноранговыми узлами, и вы используете один канал channel1 . Вы добавили бы Org1-Org5 в качестве членов канала и использовали бы контроль доступа по умолчанию, который означает, что все организации имеют доступ для чтения / записи к каналу. Затем вы должны создать свой цепной код на channel1 . На этом этапе любой клиент, выдавший сертификат / учетные данные любому из Org1-Org5, может вызвать цепной код на channel1 на любом одноранговом узле из Org1-Org5, которые присоединились к channel1 и у которых установлен цепной код .

Другим вариантом будет создание другой организации (назовем ее ClientOrg), которая выдает сертификаты для всех клиентов (Org1-Org5 будет выдавать удостоверения только для своих равноправных узлов и администраторов). Вы можете добавить ClientOrg к своему каналу, и тогда клиенты смогут также вызывать код цепочки. Я также хотел бы убедиться, что политика одобрения для цепного кода не включает ClientOrg.

Answer 2

В Ethereum или любом другом блокчейне публичный адрес не является способом подтвердить личность.У учетной записи есть открытый адрес и закрытый ключ, который вы можете использовать для подписи сообщений, чтобы доказать, что они пришли от нужного человека.Этот личный ключ и определяет вас.

В Hyperledger каждый пользователь должен принадлежать организации.Это не та система, в которой случайные пользователи могут участвовать и изменять данные по своему усмотрению.Сертификаты играют важную роль, и если они отозваны, доступ к системе больше не будет, точка.

Я предлагаю вам изучить использование Hyperledger Indy, поскольку оно имеет дело с вашим конкретным сценарием: https://www.hyperledger.org/projects/hyperledger-indy