How to authenticate to REST API and map to Fabric

Question

1. How can I create a new user account with username/password to authenticate against composer-rest-server?

2. How would I authenticate with this newly created user account against composer-rest-server?

3. How would I manage the session for that user?

4. How can I map this user to a network participant?

5. Can composer-rest-server user be mapped to more then one network participant (i.e. perform different roles)?

6. Do I need to create a wallet for each composer-rest-server user?

7. How would I share wallets across number of instances of composer-rest-server?

Answer 1

In Composer, you can model participant types, such as org.acme.Person. You can then create instances of those participant types, such as org.acme.Person#simon, and those instances are stored in participant registries.

You can then issue an identity to an instance of a participant. This process generates an enrolment ID and secret that can be sent to that participant so they can enrol. One identity is linked to one participant, but one participant can have multiple identities.

When a participant enrols using the enrolment ID and secret, an enrolment certificate is generated and placed into their wallet (configured using the keyValStore property in the connection profile). Once the enrolment certificate has been generated, the enrolment secret is made invalid. The secret can be only used one time - it is not a password.

If an enrolment certificate already exists in the wallet, then enrolment secret is not used. We have planned some future changes to make the enrolment secret optional in all APIs and CLIs so you can omit it.

When that participant submits a transaction using that enrolment certificate, the Composer chaincode extracts the enrolment ID from the enrolment certificate, and uses it to look up the participant instance that the identity was issued to. This is the "current participant".

All Composer based access control, using the rules defined in permissions.acl, is based around the current participant.

Currently, the Composer REST server supports a single enrolment ID which is specified on the command line at startup. All REST API calls to the Composer REST server use this enrolment certificate to submit transactions.

There is work being done at the moment to improve this: https://github.com/hyperledger/composer/issues/142

Please read this GitHub issue in detail. Since this work is still in-progress, there is no user documentation for configuring Composer REST server security.

There are some interesting requirements in your list:

3. How would I manage the session for that user?

There are API keys, but there is no easy way to retrieve or manage API keys. I have ideas about extending the REST server UI (Swagger UI) to manage API keys, but nothing concrete yet.

5. Can composer-rest-server user be mapped to more then one network participant (i.e. perform different roles)?

A users wallet can currently contain multiple identities, but only one of them is used by default. The user can choose the default identity by submitting a REST API call. Is that sufficient?

6. Do I need to create a wallet for each composer-rest-server user?

Each user has their own set of wallets. A default wallet is created when the user logins for the first time. A user can create multiple wallets, but only one of them is used by default. The user can choose the default wallet by submitting a REST API call. Are you looking to share wallets between users?

7. How would I share wallets across number of instances of composer-rest-server?

You need to use a persistent data store such as MongoDB to persist the wallet data across multiple instances; again, this is work in-progress and not yet documented.

I suggest that since this is in-progress work we move the discussion to the GitHub issue :-)