I need to use a database (mysql/mongodb) instead of files to store the user's wallet identity into hyperledger-fabric.
The Fabric client SDKs only provide file-system and CouchDB wallet storage out-of-the-box so you have two options:
Write your own WalletStore implementation that stores and retrieves data from MongoDB.
Store the client credentials however you want (in your database of choice or any other location), and then pass them to the SDK directly as an X509Identity object in the identity field of the connection options.
See this tutorial and the WalletStore documentation for details of how to use a custom WalletStore implementation. You might also refer to the CouchDB store implementation as a reference.
Note that for Hyperledger Fabric v2.4 and later, the Fabric Gateway client API is the preferred API for Node, Java and Go applications. The model used with this API is for you to store client credentials however you chose (which could still be in a wallet) and then just supply an identity and signing implementation using those credentials to the API on connection. See the migration guide for details.
Related
use case
in icCube
one server instance
icCube users only need to access the reporting
icCube is used to for a standard reporting solution for an industry vertical and can be used by multiple clients, each having their own (copy of the) structures that work with their own data
a client can grant one or more users access to their own dashboards in icCube
authorization requirement
it should be possible to link authorization to the client's identity
management system (such as AD)
for others, it should be possible to assign a local admin at the client that can give access to their own environment to whom they wih
for the rest, it should be possible for a centralized admin to maintain access
a perfect job for ...
keycloak
keycloak needs for each of the requirements a seperate realm with client (see picture)
The icCube documentation only makes mention of one Realm & client.
the question
Is it possible to use multiple keycloak realms & clients with one instance of icCube?
See also icCube documentation on keycloak integration
Right now this is not possible.
The keycloak.json file is used to connect to a Keycloak server that is going to authenticate the HTTP request. So you would need somehow a way to determine which keycloak.json file to use based on the HTTP request before using it meaning having different URL and/or URLs with a specific parameter.
Possibly the multi-tenant support could be extended to be able to configure an authentication logic per tenant with the same constraint about the URL value.
Hope that helps.
It seems as though an AppSync project can only be configured with one Authorization type (API_KEY, AWS_IAM, etc.). I'm using AMAZON_COGNITO_USER_POOLS as my primary type, but I also have a (Node.js) client that I want to provision with API_KEY access.
Is this possible?
If not, can you suggest any alternatives?
The answer by Rohan works provided you don't have subscriptions; if you do have a subscription in one AppSync endpoint and mutate data in another AppSync endpoint then while the data behind the scenes is updated, the subscription won't update (which makes sense, as the subscription is a attached as a listener within an AppSync endpoint). Until AppSync supports multiple methods you might want to give IAM a try; there's some details here on how to get it to work with Cognito in app + a Lambda. The example there is in python but for node.js you would generate signatures with something like https://www.npmjs.com/package/aws4 . The same method would work if running your node.js client elsewhere provided you generate some API keys
There are two approaches to solve for your use case.
You can provision a separate AppSync endpoint (you can create up to 25 per region within an AWS account) with the same schema and configure it with a different authorization scheme. Use this approach only if you need hard isolation between the endpoints.
As of May 2019, AWS AppSync supports multiple authorization schemes for a GraphQL API. You can enable AMAZON_COGNITO_USER_POOLS as the default auth scheme and API_KEY as the additional auth scheme. This is the recommended approach and also works with subscriptions, which addresses Matthew’s concern in another answer.
As of May 2019, AWS AppSync announced the support for multiple auth types in the same API. https://aws.amazon.com/blogs/mobile/using-multiple-authorization-types-with-aws-appsync-graphql-apis/
I do have some data stored in my Real-Time Firebase database. I am willing to expose some of this data via a REST API to my B2B customers.
I know that Firebase is itself a REST API but its authentication mechanisms don't fit my needs. I am willing my customers to access the API with a simple API Key passed in the HTTP request headers.
To summarize, I need an API layer sitting on top of my Firebase real-time database with the following properties:
Basic Authentication via an API key passed in the HTTP request headers
Some custom logic that makes sure customers respect the API limits (maximum requests per day for example)
The only thing I can think of is implementing this layer in AWS lambda but that also sounds a bit off. From the lambda, I would have to access my Firebase database and serve that data. That seems too many network requests; something native to Firebase would be great.
Thanks,
Guven.
Why not have a simple API which provides them an Oauth token for the original firebase REST API if they have the correct Api Key
It'll be more secure as only you'll be able to make the tokens as only you'll have the service account private key. Also saves you the headache of making a whole REST API. Also the Oauth tokens expire relatively quickly so it's less of a risk than a normal key that you furnish
I personally have created my own Servlets where a user posts their data if they are authenticated using an id pass combo.
In the Servlets i use the default REST API provided by Firebase with the Oauth generated in my servlet. This way, i can have the DB security rules set to false for all writes from any client api. And the REST API and their admin sdk on my server ignore the security rules by default.
After some research, I have decided that AWS is the best platform such API related features.
Gateway API lets you setup your API interface in a matter of seconds
DynamoDB stores your API data; you can easily populate the data here
AWS Lambda lets you write the integration code between Gateway API and DynamoDB
On top of these, the platform offers these features out of the box:
Creation & handling and verification of API keys for authentication
Usage plans to make sure that API consumers don't exceed your API usage limits
Most of what I was looking for is offered in these AWS services.
I am developing a Rest service with Web API. The service only requires one login credential as it is used by an application developed by a third party. If I use the project template with "Individual User Accounts", I have to have a SQL server running(?), which is an overkill to support a single username and password. How about the LocalDB comes with VS 2013 ?
"Windows Authentication" cannot be used because the service is accessed from the Internet.
What is the proper way to authenticate ?. Are there any "in memory" or config file providers that come with Web API ? I know there is Asp.net Identity package, but It uses entity framework as a provider. Can anyone please suggest ?
You can create a custom store for ASP.NET Identity and it could be memory or a config file. Here is a tutorial on creating a custom store in ASP.NET Identity. I would not put it in memory because you will most likely want to change the password and that would require a recompile and redeploy. Personally I would just use SQL Express or SQL Compact as they take minimal resources and rewriting the data store seems like a lot of work for little benefit in this scenario.
No matter how do you want to authorize the call, the users has to be present in a database or cache to check the validity of the provided user. Microsoft will offer you out of the box a solution based on SQL server or some of their own products.
If you want to implement you own user check, you will probably have to take care of the authentication by yourself. This means that you will have to check the HTTP header by yourself and reject or accept the request by yourself.
My question is, why do you want to use some "in memory" provider? The users has to be somewhere. Why not a SQL express?
In MongoLab you generate an API key and then anyone can access your database using REST API.
Usual case is to use the REST api directly from Ajax clients.
But this gives anyone complete write access to your database, which is security hole.
Is there a way to generate an API key which will give READ ONLY access to the database
Currently, all API keys have read and write access to the databases associated with the user's account. If you need to expose a read-only API we recommend building your own with one of the many frameworks available like Express or Sinatra.