ACL Hyperledger Composer: доступ для чтения для разных участников - PullRequest
Новая
       22

ACL Hyperledger Composer: доступ для чтения для разных участников

0 голосов
/ 06 мая 2018

У меня есть 3 разных участника, идентифицированных по собственному идентификатору: поставщик, реквестер и потребитель. Поставщик должен иметь возможность видеть банковский счет Заявителя, но не от Потребителя Как я могу определить правило?

Первый файл модели: 

namespace org.acme.biznet

abstract participant Member identified by memberId {
o String memberId
o String name
o String email
}

// Sensorbesitzer, z.B private Personen, Haushalte etc.
participant Provider identified by providerId extends Member {
o String providerId
--> SDTWallet sdtWallet
--> BTCWallet btcWallet
--> Account account
}

// Sensordatenabnehmer, z.B unabhängiger Dienstleister
participant Requester identified by requesterId extends Member {
o String requesterId
--> SDTWallet sdtWallet
--> Account account
}

// Datenkonsument, der die aufbereitete Sensordaten kauft, z.B Behörden, 
Regierung etc.
participant Consumer identified by consumerId extends Member {
o String consumerId
--> Account account
}
// Geldkonto von den Netzwerkteilnehmern.
asset Account identified by accountId {
o String accountId
o Double balance default = 0.0
--> Member owner 
}

Как я уже упоминал, провайдер должен иметь возможность видеть свою учетную запись и учетную запись реквестера. 

rule ProvidersReadAccesstoAccount {
description: "Providers have read access to own Account and Account of 
Requester"
participant: "org.acme.biznet.Provider"
operation: READ
resource: "org.acme.biznet.Account"
action: ALLOW
}

С этим правилом я вижу все 3 из них. Я создал это: 

rule ProvidersNoAccessToAccount {
description: "Providers have no access to Account of Consumer"
participant: "org.acme.biznet.Provider"
operation: READ
resource(r): "org.acme.biznet.Account"
condition: (r.owner.getIdentifier() == "org.acme.biznet.Consumer")    
action: DENY
}

Но это не сработает. Как это должно быть определено?

1 Ответ

0 голосов
/ 09 мая 2018

Вы должны быть в состоянии заменить свое последнее правило чем-то вроде этого (ниже)? Используйте getFullyQualifiedType(), чтобы получить его, как показано: (FYI getIdentifier() получает фактический идентификатор участника-владельца, например, «123»). 

rule DenyProviderAccessToConsumer {
    description: "Disallow Provider -> Consumer"
    participant(p): "org.acme.biznet.Provider"
    operation: READ
    resource(r): "org.acme.biznet.Account"
    condition: (r.owner.getFullyQualifiedType() == "org.acme.biznet.Consumer")   
    action: DENY
}

а также - это «более лаконичное» правило должно быть выше вашего более «широкого» правила ProvidersReadAccesstoAccount в файле permissions.acl, чтобы это правило оценивалось по правилу, которое я предоставил выше.

...