add authentication link to test mode topic

src/markdown-pages/docs/managers/core-manager.md

@@ -58,10 +58,10 @@ The following are properties used to configure the Core Manager:
 | Property: | Resource String Pattern CPS Property |
 | --------------------------------------- | :------------------------------------- |
 | Name: | core.resource.string.[length].pattern |
-| Description: | Defines the pattern of characters within a string of a specified length.  The patterns are from the Galasa ResourcePoolingService which uses a homegrown syntax.   |
+| Description: | The Resource String Pattern CPS property allows Galasa to form a string based upon a certain standard or pattern, for example, must begin with the letter `A`, must end with a numeral. The patterns are formed from the Galasa `ResourcePoolingService` which uses a custom syntax. This property is used when the Core Manager provisions a `@ResourceString` into a test.  This string can used for anything within the test class, for example, to create new z/OS PDS names, or a piece of data that the test will use. The string must be unique to that test across all the other tests within the Ecosystem.  |
 | Required:  | No |
 | Default value: | {A-Z} for each byte for the specified length |
-| Valid values: | For each character the value can be a constant or a random choice from a literal, eg {A-Z results in a single character between A and Z inclusive. {0-9} or {a-zA-Z0-9} are options. DFH{A-Z}{0-1}{0-9}{0-9}{0-9}, results in DFHA1789 for example, the 4th character can only be 0 or 1. 
+| Valid values: | For each character the value can be a constant or a random choice from a literal, eg {A-Z} results in a single character between A and Z inclusive. {0-9} or {a-zA-Z0-9} are options. DFH{A-Z}{0-1}{0-9}{0-9}{0-9}, results in DFHA1789 for example, the 5th character can only be 0 or 1. 
 | Examples: | <code>core.resource.string.8.length={A-Z}{A-Z}{A-Z}{A-Z}{A-Z}{A-Z}{A-Z}{A-Z}<br> </code> |
 
 </details>

src/markdown-pages/docs/writing-own-tests/running-test-modes.md

@@ -20,13 +20,18 @@ There are three modes in which you can run a Galasa test:<br><br>
 -  remotely, by submitting the test to run in the Galasa Ecosystem<br> 
 
 
+If you are running a test locally but using a shared configuration that is hosted by the Galasa Ecosystem, or running a test remotely by submitting the test to run in the Galasa Ecosystem, you are interacting with the Galasa Ecosystem. 
+
+Before you can interact with the Galasa Ecosystem, you must authenticate with it by using a personal access token. Tokens are stored in the `GALASA_TOKEN` in the `galasactl.properties` in your Galasa home folder. You can request a personal access token by using the Galasa Web UI. For more information about setting up authentication with an Ecosystem, see the [Configuring authentication](../ecosystem/ecosystem-authentication) documentation.
+
+
 The mode in which you choose to run a test depends on what you are trying to achieve. Use the following information to understand which mode is most appropriate for a given scenario. 
 
 
 ## <a name="locally"></a>Running a test locally
 
 
-When you run a test locally, without using shared configuration, everything runs on your local machine. The Galasa bootstrap file is blank and makes no reference to an ecosystem. The Galasa framework is launched within the JVM on the local machine and the local file system holds all the configuration that is used by the test. The test runs in the local JVM and all test results and artifacts are stored on the local disk. 
+When you run a test locally, without using shared configuration, everything runs on your local machine. The Galasa bootstrap file is blank and makes no reference to an Ecosystem. The Galasa framework is launched within the JVM on the local machine and the local file system holds all the configuration that is used by the test. The test runs in the local JVM and all test results and artifacts are stored on the local disk. 
 
 ![running in local mode:](running-local.svg)
 
@@ -35,21 +40,35 @@ You can run a test in this mode by using the `runs submit local` <a href="https:
 
 ## <a name="remotely"></a>Running a test in the Galasa Ecosystem
 
-To submit your test to an Ecosystem for remote execution, the Galasa bootstrap is set to the URL of the Galasa Ecosystem in which you want to run your test. The configuration of the test is also held within that ecosystem, and Galasa starts up in a container in which the test code will run. The test results and artifacts are stored in a database within the specified ecosystem, and users on client machines can view the test results. 
+To submit your test to an Ecosystem for remote execution, the Galasa bootstrap is set to the URL of the Galasa Ecosystem in which you want to run your test. The configuration of the test is also held within that Ecosystem, and Galasa starts up in a container in which the test code will run. The test results and artifacts are stored in a database within the specified Ecosystem, and users on client machines can view the test results. 
 
 
 ![running remotely:](run-remote.svg)
 
-You can run a test in this mode by setting up your bootstrap file to refer to the ecosystem that you want to use and running the `runs submit` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit.md" target="_blank"> Galasa CLI</a> command.
+After configuring authentication, you can run a test in this mode by setting up your bootstrap file to refer to the Ecosystem that you want to use and running the `runs submit` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit.md" target="_blank"> Galasa CLI</a> command.
 
 ## <a name="hybrid"></a>Running a test locally but using shared configuration
 
-When you run a test locally, but using shared configuration, the Galasa bootstrap is set to the URL of the Galasa Ecosystem where the shared configuration is stored. The Galasa framework is launched within the JVM on the local machine, but the framework consults the remote ecosystem to read configuration data, but not the credentials properties as these are drawn from a local file. This is the key difference between running a test in this "hybrid" mode versus running a test locally without using shared configuration. In hybrid mode, the test still runs in the local JVM and all test results and artifacts are stored on the local disk. 
+When you run a test locally, but using shared configuration, you need to run the `galasactl auth login` command to access the remote system using the Galasa bootstrap. You can then unset the bootstrap so that your local `bootstrap.properties` file is used, or alternatively you can refer explicitly to the local bootstrap file. For more information about the `galasactl auth login` command, see the [Configuring authentication](../ecosystem/ecosystem-authentication) documentation.
+
+
+The Galasa framework is launched within the JVM on the local machine, but the framework consults the remote Ecosystem to read configuration data, but not the credentials properties as these are drawn from a local file. This is the key difference between running a test in this "hybrid" mode versus running a test locally without using shared configuration. In hybrid mode, the test still runs in the local JVM and all test results and artifacts are stored on the local disk. 
 
 
 ![running in local mode with shared configuration:](hybridrunmode.svg)
 
-You can run a test in this mode by setting up your bootstrap to refer to the ecosystem in which the shared configuration is stored, and using the `runs submit local` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit_local.md" target="_blank"> Galasa CLI</a> command. 
+To run tests in hybrid mode, add the following properties into your local `bootstrap.properties` file:
+
+```
+framework.config.store=galasacps://my.ecosystem.url/api
+framework.extra.bundles=dev.galasa.cps.rest
+```
+
+where: <br>
+- `https://my.ecosystem.url` refers to the Web UI used to allocate tokens and <br>
+- `framework.extra.bundles` tells the Galasa framework to load the `dev.galasa.cps.rest` extension. This extension tells the Galasa framework how to handle URLs that start with `galasacps` as the *scheme* part of the URL. <br>
+
+After setting the `GALASA_TOKEN` to be a valid token for the Ecosystem from which the CPS property values will be drawn, log into the Ecosystem by running the `galasactl auth login` command. You can then run a test in hybrid mode by setting your bootstrap to refer to the Ecosystem in which the shared configuration is stored, and using the `galasactl runs submit local` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit_local.md" target="_blank"> Galasa CLI</a> command. 
 
 ### <a name="whenremote"></a>When to run a test in the Galasa Ecosystem
 
@@ -60,7 +79,7 @@ Running a test remotely is useful in the following scenarios:
 
 If you are able to dynamically provision a system, then running tests from a local JVM can work well, as the system under test might have few resource contraints and can be used exclusively by the tests before being de-provisioned. However, if you want to run many test in parallet, you cannot do so reliably from a single system using the local JVM method on one user account. Any contention to name test runs uniquely, or other stateful changes in the test framework might cause the tests to clash, over-write each other, fail, or produce unexpected results. Running multiple tests in series can avoid some of these issues but running large numbers of tests in this way can take a long time. 
 
-To reliably run many tests in parallel, deploy your tests to the Galasa Ecosystem, letting the ecosystem manage the test runs, and the Galasa Manager components manage any shared or constrained resources. 
+To reliably run many tests in parallel, deploy your tests to the Galasa Ecosystem, letting the Ecosystem manage the test runs, and the Galasa Manager components manage any shared or constrained resources. 
 
 - <b>Test results and reports need gathering from a single point. For example, when test results need reporting or exporting to another report-generating system, or when bug investigation can proceed by independent inspection test results and artifacts.</b>