How exactly the transaction is happening in Corda. Is it using node Identity for transaction signing. If I created multiple accounts under a node, will it use Node Identity for transaction signing or is it using account. Where the keys belongs to a node are stored in the Corda network? It will be great help if someone can provide the documentation link for more detail on transaction signing and node identity storage.
Related
I want to have a per client namespace and storage in my kubernetes environment where a dedicated instance of app runs per client and only client should be able to encrypt/decrypt the storage being used by that particular client's app.
I have seen hundreds of examples on secrets encryption in kubernetes environment but struggling to achieve actual storage encryption that is controlled by the client. is it possible to have a storage encryption in K8s environment where only client has the knowledge of encryption keys (and not the k8s admin) ?
The only thing that comes to my mind as suggested already in the comment is hashicorp vault.
Vault is a tool for securely accessing secrets. A secret is anything
that you want to tightly control access to, such as API keys,
passwords, or certificates. Vault provides a unified interface to any
secret, while providing tight access control and recording a detailed
audit log.
Some of the features that you might to check out:
API driven interface
You can access all of its features programatically due to HTTP API.
In addition, there are several officially supported libraries for programming languages (Go and Ruby). These libraries make the interaction with the Vault’s API even more convenient. There is also a command-line interface available.
Data Encryption
Vault is capable of encrypting/decrypting data without storing it. The main implication from this is if an intrusion occurs, the hacker will not have access to real secrets even if the attack is successful.
Dynamic Secrets
Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up. This means that the secret does not exist until it is read.
Leasing and Renewal: All secrets in Vault have a lease associated with them. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.
Convenient Authentication
Vault supports authentication using tokens, which is convenient and secure.
Vault can also be customized and connected to various plugins to extend its functionality. This all can be controlled from web graphical interface.
When integrating the WSO2 Identity Server (5.6.0) and WSO2 APIM (2.5.0). I came across one scenario where I want the token which I am generating while logging into IS should be used also for invoking APIs in APIM which are created by the same user.
I am creating user in IS and it is getting reflected in APIM but the token which is generated for IS is getting saves in IDN_OAUTH2_ACCESS_TOKEN of IS DB and for APIM while invoking any APIs for the same user, the token are getting saved in IDN_OAUTH2_ACCESS_TOKEN of APIM.
I want to use the same token which was generated in IS to invoke APIs which the same user created in APIM.
Any guidance in this direction will help me to understand.
Thanks
In a distributed deployment of APIM, you can use IS as the key manager node. The following document explains how to set it up.
https://docs.wso2.com/display/AM260/Configuring+WSO2+Identity+Server+as+a+Key+Manager
This document explains (step 3) how to share databases between APIM and IS. You can use the same to achieve what you want.
In short, you need to configure IS to use the APIM DB (shared between 2 nodes) instead of its own IS DB.
You also have to map the Application in the API store to the OAuth app you have created in IS. See this doc for that.
https://docs.wso2.com/display/AM260/Provisioning+Out-of-Band+OAuth+Clients
If I share a user's Firebase device ID key (for a user who has my app installed) with other Firebase service providers, can they send messages from their account (using their authentication key) to a user who has my app installed?
Yes I do realize the process of sharing a user's Firebase device ID key could be problematic. The problem I am trying to solve is that I want multiple providers to be able to send messages to a user who has my app installed.
The Firebase Instance ID (also known as a registration token, or FCM token) identifies an installation of your app on a specific device.
Sending messages to such tokens in a project always requires an additional form "authentication.
The Firebase Cloud Messaging versioned REST API requires that the user has a service account. If you create a service account for each of your service providers, you grant them complete access to your Firebase project. So they can't only send FCM messages, they can also access every other Firebase product: e.g. delete your database, read all your users, etc.
The legacy REST API for Firebase Cloud Messaging instead uses a Server Key to authorize its callers. If you share your FCM server key with other service providers, they can only send FCM messages with that key. But they can send whatever messages they want to whatever user.
You might want to consider setting up your own API endpoint on Cloud Functions for Firebase. That way you can determine yourself how to secure that API, and what you allow your service providers to send to what users of your app.
Assuming that the Firebase Device ID Key you're referring to is the FCM Registration token, then having the value alone won't enable others to send a message to it without the corresponding Server Key it is associated with.
For your use-case of allowing multiple senders to a single app, you could refer to the official documentation on Receiving messages from multiple senders. I believe my answer here could also be helpful.
Azure CosmosDB - MongoDB provides keys for Read-Write and Read Only at account level.
CosmosDB SDK and API are there through which users can be created and access can be define at database and document level.
• But What I need to do is to create a pair of username and password with restricted access to a MongoDB database similar to one provided by installable MongoDB.
• How a user can connect only CosmosDB MongoDB database using RoboMongo.
Highly appreciate any help.
Amit -
Today, Cosmos DB access are provided by using two keys, Master Key and Read Only key. However, if you want to restrict user access per collection, per document etc, you have to use Resource Tokens. You can read more about it here and please take a look at CH9 video to see the implementation details. Resource Token service can be implemented as an Azure Function. Here is code to get you started.
But if you are using RoboMongo you have to Use the keys as define in this document. At this time you cannot define different users and Keys for a Database.
I'm new to the AWS services and would like to understand if it is possible to use dynamodb and cognito sync in this specific scenario:
publish data from a company office to few tables on one central dynamodb
use cognito sync in a mobile app to periodically get those tables copied to storage local to the mobile device (unidirectional sync from central dynamodb to the remote mobile devices)
it is my understanding that cognito sync is normally used to sync profile data of the user, but i would like to understand if it is possible to use it in this different way (one dynamodb repository for all the authorized mobile users).
Thank you,
Mario
No, Amazon Cognito Sync provides its own per-identity storage (ie: storage not shared between your app users) but if you want to have a shared DynamoDB database, you can still use Amazon Cognito Identity with a role that gives read access to those tables to your users.
Albert
You can use AWS Cognito Sync Events to trigger a AWS Lambda. Then use the Cognito Sync data passed to event, to update the AWS Dynamodb table.