I have written a CorDapp where I want to treat counterparty nodes differently based on their "role".
For example, I may want to check that a counterparty node has the "cash issuer" role before requesting cash issuance from them.
What's the best way to define public node roles in this way?
As of Corda 3, there isn't built-in support for this feature. Support is expected to be added in a future release.
In the meantime, there are several workarounds:
Using an oracle, as Kid101 mentions above. The oracle would store role information that could be queried by nodes
The roles could be retrieved via a HTTP call within the flow - see the Flow HTTP sample
The roles could be stored in the node's database and retrieved within the flow - see the Flow DB sample
Each node could have a flow pair that returns the node's role
The roles could be hardcoded in a configuration file installed on each node - see How to provide a CorDapp with custom config in Corda?
The roles could be hardcoded in the CorDapp's flows
Related
I am experimenting with Hash Time-Lock Contracts in Corda, using the Corda account-based model. It seems to me that, to transact with an account, you must always obtain an Anonymous Party to serve as its public key, via subflow RequestKeyForAccount. And it seems that you will always obtain a different key each time you RequestKeyForAccount, even for the same account.
Assuming the above statements are correct, I am finding it impossible to implement the contract, as the contract must be able to identify whether the public key invoking it belongs to the "locker" or the "lockee" party. The Anonymous Party will always be different, and will never match either the "locker" or the "lockee," because it will be different every time I invoke RequestKeyForAccount.
I have also tried tackling the problem in a different way, by storing "locker" account and "lockee" account in my persisted state - but, the contract does not have access to the account that is invoking it. It has access to the signers - which are AbstractParties. The account invoking the transaction does not seem obtainable.
Bottom line, I cannot implement a contract that tries to ascertain whether the account invoking it matches a particular account stored within the associated state, due to the random anonymized values returned by RequestKeyForAccount; and due to the inaccessibility of account when all I can access are the signers of the transaction, i.e. AbstractParties. I'd appreciate if somebody can tell me if I am off-base in any of my statements.
Always remember that Accounts in Corda are only logical entities. They do not sign transactions and they do not invoke flows in the cordapp. It's their hosting node that does it on behalf of the accounts they own.
So, as also stated in training.corda.net, if you want to restrict access to certain states to a particular account, you have to manage it outside of Corda (for example, create a RPC user that is linked to an account at application level, with the needed restrictions):
Data access restrictions, i.e. restricting users (i.e. Corda accounts) to interact only with states that they own, is the CorDapp developer's responsibility as implementing them is outside of Corda’s scope.
Does Corda node support the concept of an organization and users in the organization? The ORG user must have visibility to transactions of the node. And is it possible to add users within this Organization who can be part of selected transactions?
Yes, you can do it with Corda. I see two ways:
Use the Account library. Accounts are "logical" entities, i.e. subset of the node's vault. An ORG can be the Corda node and the users can be accounts owned by the node, which has complete visibility of the transactions. You can add as many accounts as you want. Note that an account only has public keys, the private keys are owned by the Corda node owner of the accounts. The flows are effectively ran by the Corda node, not by the Account themselves who are just effectively states that only have a name and a set of public keys (but not a X.509 identity, so they are not registered to the network. Only the Corda node is). A typical use case of this is a Group Company X (i.e the Corda node) who owns some Subsidiary Companies (its accounts). More info: https://training.corda.net/libraries/accounts-lib/ and https://github.com/corda/accounts/blob/master/docs.md
Use the Business Network Membership: https://docs.corda.net/docs/corda-os/4.8/business-network-membership.html. In this case you have different Corda nodes connected to the same network, and a subset of these node share a "logical" network, which is made at application level in which you can set the roles and memberships. In pratice, this is a cordapp shared between them where there are states that identify an organization and its rules.
These two above are ways to effectively create "organizations". In Corda then you also have the Observer parties, who are parties that just want to be notified of some transactions without effectively be part of them.
Do you have to be a known party on the network to make a transaction?
Can an anonymous user off the network interact with the blockchain?
When joining the network, a node needs to obtain a network certificate provided by the network's doorman. This certificate ties the node to a specific real-world identity. When messaging other nodes, a node must use this certificate to allow the receiving nodes to verify who they are transacting with.
However, suppose a node is working with other nodes to build a transaction. Although the node must reveal its identity to the other nodes they are building the transaction with, it can choose to identify itself in the transaction being built using an anonymous one-time public key, rather than a real-world identity.
This means that the node's identity is not stored on the ledger for all to see, and is only known to the nodes with whom the transaction was originally built.
You can also imagine scenarios where even though the node's identity is well-known, the identity of the actual user is not. For example, a node representing an auction house may place a bid on the behalf of an anonymous user.
Hi is Corda a recommended platform for Digital Identity? For a use-case of Account based-Certification. (i.e. i as a user store my certificates/Identity on the ledger and access it via a password/key where i would go through a node, at the same time to allow a specified certificate only to be seen by a specified party. Where the control is on the user/account level and not a node level. Which means i could specify which certificate/identities i would want to allow another organisation to access)
for blockchain technologies I understand that the data is duplicated across all nodes as long as the user have the key the user can access his own data even if the node is a newly joined node to the network.
As i understand also Corda doesn't support multiple identities on a single node as it is node basis. What will be the approach for this case using Corda platform?
first of all - Corda is not like Ethereum, Fabric and any other blockchain where all nodes store same common state. In Corda network nodes store only transactions and states they were participating in or observing. So its more peer-to-peer rather than broadcast.
Check here for more details:
https://docs.corda.net/key-concepts-ledger.html
From this perspective Corda is probably not the best candidate for public Identity network.
For solution about self-sovereign identity management I would recommend to have a look at something like Sovrin(Indy). You can use it to build app on top of the platform. Or just learn their design ;)
Corda may have sense in Identity context if there are different organisations and they exchange its members identity info for some reason. Then node will be Identity Manager and store info about people who gave it its credentials of any kind. So Identity will be mere state here, I think. Corda itself will play transport and storage role. Not a blockchain-style decentralized way at all but may be useful in some cases.
How can I route a task based on user attributes in IBM BPM 8.5.6?
In my case I have a list of attributes assigned to each users. For example a user will have an attribute called Region and this can have multiple values. So what we do is keep it as a comma separated string. Like REG1,REG2,REG3. Now when a task is initiated there will be a region associated with it. So I want this task to be routed to only those users who have that region value set.
I've created a team filter service and filter out a list of users. This works fine but the problem here is if we add a new user with appropriate region or add new regions to existing users these tasks are not visible to them. Is there any way to dynamically update the user list?
PS: I can create one group per region or one team retrieval service per region as there will be 100s of regions.
IBM BPM won't update the user repository all the time, there are certain events that will trigger an update:
http://www-01.ibm.com/support/knowledgecenter/SSFPJS_8.5.6/com.ibm.wbpm.admin.doc/topics/sync_users_and_groups.html
Quoting the article (because IBM articles may vanish at some point):
IBM Business Process Manager implicitly synchronizes external users and groups based on the following triggers:
Upon startup of a cluster member or server, all available groups (without members) are synchronized, so that all external groups are available for IBM BPM modeling and execution.
When a user logs in to a IBM BPM web application, such as Process Portal, for the first time, that user is created in the IBM Business Process Manager database.
When a new or existing user logs in to a IBM BPM web application, such as Process Portal, that user's full name and group memberships are updated. The groups the user belongs to are queried from the external user registry, and the IBM Business Process Manager database content is updated to reflect the current state.
When a REST call is triggered because a user that was newly registered in a federated repository (using an LDAP server) is not yet known to IBM Business Process Manager, synchronization of external users and groups with IBM Business Process Manager takes place. This synchronization is done only once.
You can also trigger synchronization via the process admin console or manually with usersSync or usersFullSync commands