I am trying to integrate Accounts Functionality in my CordApp, and was going through the supply chain demo https://github.com/corda/accounts-demo-supplychain
Here is a list of my queries:
What is the purpose of the Account Broadcast flow?, not mentioned in the readme file https://github.com/corda/accounts-demo-supplychain/blob/master/workflows/src/main/kotlin/com/accounts_SupplyChain/flows/AccountBroadcast.kt
Is the purpose of Share Account Flow, only that the counter party node's know's the account identity, what if I don't want to use it?
Since account is a sub-vault of the node's vault, that data is visible to that node right?
To share account infos with other nodes on in the zone. You need to do this so that they know which node and account belongs to.
Same as above. You don't have to use it.
Yes.
Related
I want to make an app where parents can buy a subscription for their children (one subscription per child) but I wonder how the corresponding accounts in Firebase would look like (buying the subscriptions themselves is out of scope of this question).
Are there best practises I should follow here?
I'll have a parent account in Firebase I guess
how can I create the children's accounts and how do I communicate their (generated?) credentials to them?
Thanks in advance for your insights!
Firebase Authentication maintains a flat list of accounts per project. There is no built-in relations between any of the accounts, unless they are linked (which is not what you want here).
The best I can think of for the structure is to add a custom claim to the child accounts identifying their parent (and vice versa if needed). This needs to be done from a trusted environment (such as your development machine, a server you control, or Cloud Functions/Cloud Run). A local (Node.js, or other supported language) script or this extension that sets claims based on a Firestore document are probably the easiest way to get started with this.
If you choose to create the kid's accounts in a trusted environment with an Admin SDK too, you might as well add the custom claim there.
How to add Azure custom Policy for Azure Data Factory to only use Azure Key Vault during the Linked Service Creation for fetching the Data Store Credentials instead of credentials being put up directly in ADF Linked Service. Please suggest ARM or PowerShell methods for the policy implementation.
As of yesterday, the Data Factory Azure Policy integration is available which means you can now find some built-in policies that can be assigned to ADF.
One of those is exactly what you're asking for as you can see in the image below. You can find more information here
Edit: Based on your comment, I'm editing this answer with the info you want. When it comes to custom policies, it's pretty much up to you to come up with them and create what fits your needs. In your particular case, I've created one policy that does what you want, please see here.
This policy will audit your data factory linked services and check if they're using a self-hosted integration runtime. Currently, that check is only done for a few types of integration runtimes (if you look at the policy, you can see 5 of them) which means that if you want to check more types of linked services, you'll need to add them to the list of allowed values and select them when assigning the policy definition.
Bear in mind that for some linked services types, such as Key Vault, that check won't make sense since that service can't use a self-hosted IR
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.
What's the best way to set permissions on objects in Apigee BAAS entities, collections in such a way that Users can edit what they create, and others can read them? There might be a case for Admins to be able to edit everything as well.
I asked a similar question here Securing apigee baas that was more around securing the app id/secret which would be needed to make the call to update permissions, but I was wondering if there is any best practice around doing this sort of thing from a mobile application.
My initial thought would still be the service callout (not sure how Apigee-127 which was mentioned in the previous question would be any different to a service callout directly to the BAAS as to me 127 looks like I'm just writing my apis in Node.js rather than using the edge console), but I don't know if there is an easier way in terms of securing all entities, in specific collections ,created by specific users? I guess I could add a created by column which I could check from an app perspective, but this wouldn't stop someone from potentially hitting the BAAS directly and retrieving this info unless permissions are also set at an entity level requiring a user access token.
Is it possible to secure the BAAS in such a way that only calls from Edge can hit the BAAS url?
(Disclaimer: I have not tried this myself but here is a suggestion.)
API BaaS Automatically sets the path segment to the UUID of the currently authenticated user when $user is used. For example, if you sent a request with a valid access token for a user with UUID bd397ea1-a71c-3249-8a4c-62fd53c78ce7, the path /users/${user} would be interpreted as /users/bd397ea1-a71c-3249-8a4c-62fd53c78ce7, assigning the permission only to that user entity.
In this way, through your application, you can set permission for each user, and each object as soon as the objects are created from your application. Assuming you have the user authenticated, of course.
Ref: http://apigee.com/docs/api-baas/content/using-permissions
What is the best way to manage domain specific services? For eg: In a Financial domain, Should I have a global service "AccountCreation" or "CheckingAccountCreation", "CreditcardAccountreation" etc.
I am struggling whether to keep them at global level or keep them at the product level. what is the best approach?
You should probably focus in the data first: what data is there, and what data needs to stay consistent. Then focus on what the behaviours around that data are.
In a Financial domain, Should I have a global service "AccountCreation" or "CheckingAccountCreation", "CreditcardAccountreation" etc.
In this example, I would say that you have an "account" service, because you clearly have some accounts - and you probably have to ensure that, eg, you don't duplicate account numbers, apply anti-fraud rules, manage the workflow of creation, etc.
Your examples identify some behaviours: create a checking account, create a credit card account. Those would appropriately be commands that you send to the service, because they result in mutation of the data that the service owns.
If you add a "customer" service, though, that would be distinct from the accounts service: it doesn't have to be consistent with the account service, just to have a reference from accounts to customers by ID.
You also generally don't have shared behaviour that touches both parts - updating data about a customer shouldn't touch the details of their accounts (directly), and updating an account doesn't change the details of a customer.
You might have business rules in one service that change another, such as the account service listening for "a customer became a student" announced by the customer service, and then doing some internal processing.