Merge pull request #18 from UlfBj/master

Tutorial access control update.

tutorial/content/server/Access-control-servers/_index.md

@@ -37,9 +37,12 @@ the server will then forward the access token received in the client request to
 
 The ATS will as part of the validation also use the VISSv2 specified policy documents if they are found in the working directory.
 
-The ATS suports caching of access tokens, and returning a token handle to the client if cached. The cache is configured to hold max 10 tokens.
+The ATS supports caching of access tokens, and returning a token handle to the client if cached. The cache is configured to hold max 10 tokens.
 If the cache is full, caching of one more is rejected until a cached token becomes expired, or pre-emptied by other reasons.
 
+For the AT server to verify the AGT signature it needs to have access to the AGTS public key. To facilitate that it is necessary to copy the server/agt_server/agt_public_key.rsa file
+to the server/vissv2server directory.
+
 ### Server configuration
 The configuration available for the servers is whether the protocols that they implement to expose their APIS are TLS protected or not.
 The same framework that is used for generating credentials for the client-server communication described [here](https://github.com/covesa/vissr/tree/master/testCredGen/)

tutorial/content/server/_index.md

@@ -16,18 +16,38 @@ $ go build
 #### VSS tree configuration
 The server has a copy of the VSS tree that it uses to verify that client requsts are valid -
 that there is a node in the tree that corresponds to the path in a request, if a node requires an access control token, etc.
-The tree parser that is used expects the tre to have the 'binary format' that one of the VSS-Tools genertes from the vspec files.
+The tree parser that is used expects the tree to have the 'binary format' that the binary exporter of the VSS-Tools generates from the vspec files.
 To generate this the [VSS repo](https://github.com/COVESA/vehicle_signal_specification) must be cloned including the VSS-Tools submodule,
 and a file containing the binary representation must be created, which is done with the following command issued in the root directory.
 
 $ make binary
 
+However, before issuing the command above it is necessary to edit the make file to remove the --strict command parameter.
+The tool will then issue a warning in its log that an unknown attribute is detected, but the binary file is correctly generated.
+
 This generates a file with a name like 'vss_rel_4.1-dev.binary',
 which then needs to be renamed to 'vss_vissv2.binary' and stored in the vissr/server/vissv2server directory.
 
 If you want to configure the tree to include access control, access control tags as described in the
 [VISSv2 - Access Control Selection chapter](https://raw.githack.com/covesa/vehicle-information-service-specification/main/spec/VISSv2_Core.html#access-control-selection) needs to be added to appropriate tree nodes.
-This can either be done by editing vspec files directly, or using the [VSS-Tools](https://github.com/covesa/vss-tools) overlay mechanism.
+This can either be done by editing vspec files directly (example below), or using the [VSS-Tools](https://github.com/covesa/vss-tools) overlay mechanism.
+
+Adding read-write access control to the entire VSS tree can be done by modifying the root node in the spec/VehicleSignalSpecification.vspec file as shown below.
+If consent also should be required then switch the commenting between the two validate statements.
+```
+Vehicle:
+  type: branch
+#  validate: read-write+consent
+  validate: read-write
+  description: High-level vehicle data.
+```
+The above validate statement is inherited by all of the descendants of the node.
+It can be applied to any node in the tree to allow for some nodes to not be access controlled while others will be access controlled.
+Changing read-write to write-only leads to that the server will allow reading of the data without a token,
+but requiring a valid token for write requests to the data.
+
+The AT server uses the purposelist.json file to validate that a client request to access controlled data is permitted by the access token included in the request.
+It therefore necessary to ensure that this file contains purpose(s) that includes the data that is access controlled tagged in the tree.
 
 #### Command line configuration
 The server has the following command line configurations: