I have issued new participant id using Post operation of /system/identities/issue and got the card file having connection json and enrollment id and secret. Now how to generate certificate using that enrollment id and secret using the already created rest api by comopser-rest-server.
As you have found out, the Identity Issue results in a .card file (an archive containing the Connection, enrollment ID and Secret) The Secret is a one time secret and the first time the card is used the Certificates are downloaded and stored locally. After this the Secret is not valid. This works the same way for CLI, Playground and REST API.
For CLI and Playground the cards (and certificates) are stored in under the home directory of the logged in user ~/.composer/ .
For the REST server, you need to run the REST server in Multiuser mode and then there are some new endpoints under /wallet e.g. /wallet/import. The REST server stores the Cards (and certificates) in these Wallets. This is described in this document REST Server Multiuser.
A couple of additional notes: To run in Multiuser mode you also need to enable Authentication for the REST Server. When you stop the REST server the Wallets will be lost unless you persist a datastore for the REST server.
This parent doc has all the information for the REST server. REST Server Parent Doc
Related
Summary
I need to create an application where the user will subscribe to a plan that will give him a consumption of requests to the backend.
Backend: I will use nodejs and express to create the backend
Frontend: I will use reactjs to create the frontend. I will create the admin panel for user control you account.
Detail
I need to create a plugin for Wordpress that will consume these requests from the user's account. As I've never worked with this type of structure, I don't know how to guarantee that these plugins are the client's own and not someone who took his credentials and is spending his plan.
I took a look at RSA encrypt to make a data signature, but I still don't understand the best way to create this application.
I also saw about JWT but the plugin in wordpress would not have the account credentials to use JWT as login, and usually plugins and REST API using public key and secret key or api key.
Another use would be embedding a form on another site or using the REST API.
I am new to Azure API Management and will be happy to receive suggestion and advise on my implementation.
I am developing a B2B Api Channel for 3rd parties to call my services via the API Management (APIM) Gateway. On the APIM developers portal I can onboard new clients and generate API key. My struggle is how best to figure out at the underlying services who is calling?
I have considered add the API Key generated in the APIM to a database which the underlying service will call to authenticate, however, the implementation will be manual and will not be in sync when the 3rd party client goes to APIM and regenerate a new API key.
What I want is a solution that auto syncs authorization and authentication between APIM and the underlying services.
Since API keys can be replaced, you better rely on IDs to identify clients.
You can pass a client ID to a backend in a header: https://stackoverflow.com/a/42277313/2579733
Now how do you correlate APIM's client IDs with your backend's client IDs?
If there are only a few clients, you can probably update that association in your backend's database manually. If you can use the clients's email to connect the APIM client and your backend client, that's even easier (you're done).
If you will need to register many clients and the manual approach is not feasible... One way to do it is with Delegated Authentication:
Delegation allows you to use your existing website for handling developer sign in/sign up and subscription to products, as opposed to using the built-in functionality in the developer portal. It enables your website to own the user data and perform the validation of these steps in a custom way.
I never used it but it seems you can transfer the responsibility of creating new clients to a backend service (developed by you).
This way you have access to client emails, you generate IDs and can store the ID relationship in the backend as necessary.
I started composer rest server in multi user mode, using github oAuth authentication. I opened one session in chrome and one in firefox (to emulate as two different users) and authenticated using github. Now in one browser I wish to use one network card and in chrome another network card. Now when I import a network card in firefox same is reflected in Chrome as well. Doesn't it defeats purpose of authourisation ? So if one user is using its network card to perform transaction the other user will also be using the same network card as its been set as default for composer rest server. How to deal with scenario ?
The default is set at the REST Client - not the REST server. You're consuming the REST APIs as a client - as the two different blockchain identities (contained in each of your business network cards). Once a client has authenticated to the REST API, that client can add Blockchain identities to a wallet. The wallet is private to that client, and is not accessible to other clients. When a REST client makes a request to the REST server, a Blockchain identity in each clients wallet is used to digitally sign all transactions made by that client (because the identity is set as default, at the time).
The github authentication scheme is a 'delegated' authentication scheme and is using a client application (id and secret) authentication mechanism to enable a client to use the REST APIs and get a token, without needing to authenticate as a user every time.
I had this same problem. Configured the composer rest server with multi user using a jwt strategy, but I was seeing the same wallet (and the same default card) regardless of which user was logged in.
I found that the loopback-component-passport package which largely manages the wallet data was importing my users correctly, but they were all being associated with the same identity because the identity id was taken from the COMPOSER_PROVIDERS config and not the signing in user.
To fix it I modified loopback-component-passport/lib/models/user-identity.js.
Look in the UserIdentity.login method around line 100 where the userIdentity is being populated.
Change:
provider: provider,
to something like
provider: profile.sub,
depending on your payload / user profile.
After that each user will have their own identity registered in your loopback database and each signed in user should have their own wallet.
I would like to use PouchDB in a web app desktop client. I work in an environment where the computer user is generic and different persons use the same computer account. However, using my app they must log in with individual user names granting them their corresponding privileges. The system works offline, with period replication to the server.
Browsing through the documentation of PouchDB and searching the Internet I come to understand that there is no access restriction to a local PouchDB. Anyone who has access to the client/browser has in principle access to the cached data. Also implementing any sort of user access control in my web app seems to be kind of pointless. The code could simply be altered to allow access.
I came to the following possible solution and would like to know if that could work:
First contact with the central server
App sends user credentials to the server. The server encrypts a special databaseKey with the user credentials and sends this encryptedDatabaseKey back to the client app. The client app stores this encryptedDatabaseKey in localStorage, decrypts the contained databaseKey, creates and encrypts the local PouchDB using this databaseKey (e. g. crypto-pouch).
Offline usage
User logs into the app, his credentials are used to decrypt the encryptedDatabaseKey in localStorage, only then has he access to the stored data. If someone alters the code of the app he still cannot gain access to the encrypted PouchDB.
I see the following advantages:
- Without correct credentials there is no access to the local data
- Multiple users can have access to same local PouchDB since the databaseKey is identical.
- The databaseKey could even be changed regularly (app compares during a connection to the server the local encryptedDatabaseKey and the one received from the server, if they differ the app decrypts the database using the old key and encrypts it with the new)
Does this seem like a viable solution? Are there any other/better methods of securing a local PouchDB?
crypto-pouch is indeed the best method to encrypt a local PouchDB. However, I think where you say
Offline usage User logs into the app, his credentials are used to decrypt the encryptedDatabaseKey in localStorage, only then has he access to the stored data
I think it's pointless to decrypt the key and use that to decrypt the database; you might as well just as the user to create and memorize a password? Then you can use that as the key to the crypto-pouch.
I am using Kloudless to enable efficient file uploading on the client side.
However, my app currently exposes both my Kloudless API key and account id -- they will be public on the client side.
In addition to setting the trusted domains, is there any way to protect my keys right now while still enabling efficient file uploading?
You are absolutely correct that the Kloudless API Key should be kept confidential and not included on the client-side. Instead, I would use the user's Account Key instead. Account Keys function the same way as API Keys, but only provide access to the connected account.
Here is some information on using Account Keys with the File Explorer:
Account Keys can be returned from the File Explorer by setting the "account_key" option to true. They are only returned to Trusted Domains (added via the Developer Portal). Once you have them on the client-side, you can make requests using them. In addition, they can be retrieved via the backend as well.
Account Keys also come in useful when you would like to show returning users accounts they have already connected previously. By storing Account Keys for the user, you can render them on the client-side and pass them in via the "keys" option while instantiating the File Explorer, which will display the corresponding accounts to the user automatically.