In My Corda project, I want to create a special account which can have only one specific type of state and do not accept if any other state is shared with it. While other accounts on the same node can accept other states too. Is that possible in Corda. If yes, then How?
you could do this a bunch of different ways.
Maybe the easiest way would be in the flow? You just want to create a rule that ensures only a certain account can run or have a flow run involving it.
Example:
// Create account by using sub flow (from inside a flow).
val accountInfo: StateAndRef<AccountInfo> = subFlow(CreateAccount("Roger's account"))
// Then look up the account by account ID and name.
accountService.accountInfo(accountInfo.state.data.name)
accountService.accountInfo(accountInfo.state.data.identifier.id)
Take a look at this link for the source docs. Good luck!
https://github.com/corda/accounts/blob/master/docs.md
Related
I am very new to blockchain-corda R3 and i have got one task to create some party node, put some constrain and get the digital signature from the UI.
Please help me to get started with this as I have gone through the corda docs but I didn't get the solution properly.
Request you to please help me with the flow.
How we can get the digital signature from UI and also how we can sign transaction and validate in other node.
Thank you
check this out on how to create a flow and how to validate the transaction in both parties (i.e. #Initiating and #InitiatedBy flows)
by "digital signature" I guess you mean the signature of the final transaction signed by all interested parties. If this is the case, your flow needs to return a SignedTransaction object and it can be done easily just by doing this standard step at the end of your flow
return subFlow(FinalityFlow(fullySignedTx, setOf(otherPartySession)) (usage example).
If you want to see the status of all intermediary steps of a transaction before it is fully signed and notarized, Corda provides a ProgressTracker (documentation) that allows you to check create steps so that they can be showed from node terminal. You could reorganize your flows and API in order to take advantage of this.
I a newbie to AWS. My requirement is to add field-level, document-level, and collection-level permissions for reads and writes for AWS DocumentDB. One collection should accessible only from one microservice and the document should be modified only by the owner of the document(i,e user document can be modified only by that user)
I have done enough research and found, adding a restriction for accessing a DB can be done using Role-Based-Access-Control if we want to allow only for one tenant, but didn't get a clear idea of my problem statement i.e managing collection-level, document-level, and field-level permissions
Is there any other way to achieve this..?
Any help will be appreciated
Is there any way to enforce the addition of labels while creating resources? If not, is there a way to automatically label resources when creating said resources in GCP?
My use case: I need this to investigate the price in Data Studio.
Thanks.
No, you can't enforce any one to put labels on resources on GCP (same for projects). BUT you can enforce TAG automatically by inheritance. (You can't oblige a user to use them, but, by default there is a tag).
The TAG are still in preview and were named "label next gen" during the Alpha period. So, you can use them like labels, but you can enforce authorization on them (who can up view/update/delete them). This feature is very interesting because today, anyone with admin/owner roles can update/change/delete labels and you lost the control and the monitoring of your resources.
You can also put IAM condition on them and enforce organization policies accordingly.
You can't enforce users to do so. However you can:
Create a log sink if a resource is created
Use that log sink to call a cloud function that will create an alert or give a default label
If you use infrastructure as code for example Terraform, you can put a CI/CD job that will check if a label is placed, and if not reject the PR.
Suppose I have a task of updating an user via a third party API call. Is it okay to put the actual user data inside the message (if it fits)? Or should I only provide an ID in the message so the worker can retrieve the updated record from my local database?
You need to check what level of compliance is required for your infrastructure, to see what kind of data you want to put in the queue.
If there aren't any compliance restrictions, you are free to put any kind of data in your own infrastructure on AWS.
I am using IS WSO2 for authorization with XACML. I am am able to achieve authorization for static resource. But I am not sure with the design when it comes to granularization.
Example : if I have method like getCarDetails(Object User) where I should get only those cars which are assigned to this particular user, then how to deal this with XACMl?
Wso2 provides support for PIP where we can use custom classes which can fetch data from database. But I am not sure if we should either make copy of original database at PDP side or give the original database to PIP to get updated with live data.
Because Cars would be dynamic for the application eg. currently 10 cars assigned to user Alice. suddenly supervisor add 20 more car in his list which will be in application level database. Then how these other 20 cars will be automatically assigned in policy at PDP level until it also have this latest information.
I may making some mistake in understanding. But I am not sure how to deal with this as in whole application we can have lots of this kind of complex scenario where some times we will get data for one user from more than 4 or 5 tables then how to handle that scenario?
Your question is a great and the answer will highlight the key benefits of XACML and externalized authorization as a whole.
In XACML, you define generic, global rules, about what is allowed and what isn't using what I would call high-level attributes e.g. attributes of the vehicle (in your case) or the user (role, department, ...)
For instance a simple rule could be (using the ALFA syntax):
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowSameRegion{
permit
condition user.region==car.region
}
}
Both the user's region and the car's region are maintained inside the application's database. The values are read using a PIP or Policy Information Point (details here).
In your example, you talk about direct assignment, i.e. a user has been directly assigned to a vehicle. In that case, the rule would become:
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowAssignedVehicle{
permit
condition user.employeeId==car.assignedUser
}
}
This means that the assigned user information must be kept somewhere, in the application database, a CSV file, a web service, or another source of information. It means that from a management perspective, an administrator would add / remove vehicles from a user's assigned list (or perhaps the other way around: add / remove assigned users from a vehicle's assigned user list).
The XACML rule itself will not change. If the supervisor adds 20 more cars to the employee's list (maintained in the application-level database), then the PDP will be able to use that information via the PIP and access will be granted or denied accordingly.
The key benefit of XACML is that you could add a second rule that would state a supervisor can see the cars he/she is assigned to (the normal rule) as well as the cars assigned to his/her subordinates (a new proxy-delegate rule).
This diagram, taken from the Axiomatics blog, summarizes the XACML flow:
HTH, let me know if you have further questions. You can download ALFA here and you can watch tutorials here.