# Hyperledger Fabric CA sample
The Hyperledger Fabric CA sample demonstrates the following:
* How to use the Hyperledger Fabric CA client and server to generate all crypto
material rather than using cryptogen. The cryptogen tool is not intended for
a production environment because it generates all private keys in one location
which must then be copied to the appropriate host or container. This sample demonstrates
how to generate crypto material for orderers, peers, administrators, and end
users so that private keys never leave the host or container in which they are generated.
* How to use Attribute-Based Access Control (ABAC). See fabric-samples/chaincode/abac/abac.go and
note the use of the *github.com/hyperledger/fabric/core/chaincode/lib/cid* package to extract
attributes from the invoker's identity. Only identities with the *abac.init* attribute value of
*true* can successfully call the *Init* function to instantiate the chaincode.
## Running this sample
1. The following images are required to run this sample:
*hyperledger/fabric-ca-orderer*, *hyperledger/fabric-ca-peer*, and *hyperledger/fabric-ca-tools*.
These images are new in the v1.1.0 release of the *github.com/hyperledger/fabric-ca*.
In order to run this sample prior to the v1.1.0 release, you must build these
images manually as follows:
a) pull the master branch of the *github.com/hyperledger/fabric* and
*github.com/hyperledger/fabric-ca* repositories;
b) make sure these repositories are on your GOPATH;
c) run the *build-images.sh* script provided with this sample.
2. To run this sample, simply run the *start.sh* script. You may do this multiple times in a row as needed
since the *start.sh* script cleans up before starting each time.
3. To stop the containers which are started by the *start.sh* script, you may run the *stop.sh* script.
## Understanding this sample
There are some variables at the top of *fabric-samples/fabric-ca/scripts/env.sh* script which
define the names and topology of this sample. You may modify these as described in the comments
of the script in order to customize this sample. By default, there are three organizations.
The orderer organization is *org0*, and two peer organizations are *org1* and *org2*.
The *start.sh* script first builds the *docker-compose.yml* file (by invoking the
*makeDocker.sh* script) and then starts the docker containers.
The *data* directory is a volume mount for all containers.
This volume mount is not be needed in a real scenario, but it is used by this sample
for the following reasons:
a) so that all containers can write their logs to a common directory
(i.e. *the *data/logs* directory) to make debugging easier;
b) to synchronize the sequence in which containers start as described below
(for example, an intermediate CA in an *ica* container must wait for the
corresponding root CA in a *rca* container to write its certificate to
the *data* directory);
c) to access bootstrap certificates required by clients to connect over TLS.
The containers defined in the *docker-compose.yml* file are started in the
following sequence.
1. The *rca* (root CA) containers start first, one for each organization.
An *rca* container runs the fabric-ca-server for the root CA of an
organization. The root CA certificate is written to the *data* directory
and is used when an intermediate CA must connect to it over TLS.
2. The *ica* (Intermediate CA) containers start next. An *ica* container
runs the fabric-ca-server for the intermediate CA of an organization.
Each of these containers enrolls with a corresponding root CA.
The intermediate CA certificate is also written to the *data* directory.
3. The *setup* container registers identities with the intermediate CAs,
generates the genesis block, and other artifacts needed to setup the
blockchain network. This is performed by the
*fabric-samples/fabric-ca/scripts/setup-fabric.sh* script. Note that the
admin identity is registered with **abac.init=true:ecert**
(see the *registerPeerIdentities* function of this script). This causes
the admin's enrollment certificate (ECert) to have an attribute named "abac.init"
with a value of "true". Note further that the chaincode used by this sample
requires this attribute be included in the certificate of the identity that
invokes its Init function. See the chaincode at *fabric-samples/chaincode/abac/abac.go*).
For more information on Attribute-Based Access Control (ABAC), see
https://github.com/hyperledger/fabric/tree/release/core/chaincode/lib/cid/README.md.
4. The orderer and peer containers are started. The naming of these containers
is straight-forward as is their log files in the *data/logs* directory.
5. The *run* container is started which runs the actual test case. It creates
a channel, peers join the channel, chaincode is installed and instantiated,
and the chaincode is queried and invoked. See the *main* function of the
*fabric-samples/fabric-ca/scripts/run-fabric.sh* script for more details.
This work is licensed under a Creative Commons Attribution 4.0 International License