Skip to content

Commit

Permalink
Merge pull request #832 from galasa-dev/mcobbett-auth-updates
Browse files Browse the repository at this point in the history
Corrections and additions to the authentication documentation section, tokens deleting...etc.
  • Loading branch information
jt-nti authored Sep 26, 2024
2 parents e121781 + 8c333d4 commit 190bc53
Showing 1 changed file with 38 additions and 9 deletions.
47 changes: 38 additions & 9 deletions src/markdown-pages/docs/ecosystem/ecosystem-authentication.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,13 +3,14 @@ path: "/docs/ecosystem/ecosystem-authentication"
title: "Configuring authentication"
---

Before interacting with a Galasa Ecosystem using the Galasa command line tool (galasactl), you must be authenticated with it. Galasa uses personal access tokens to authenticate users who want to interact with a Galasa Ecosystem provided by the `GALASA_BOOTSTRAP` environment variable or through the `--bootstrap` flag.
Before interacting with a Galasa Ecosystem using the Galasa command line tool (`galasactl`), you must be authenticated with it. Any `galasactl` command which connects to a remote Galasa service needs to know the address of that service. A URL can be configured in the `GALASA_BOOTSTRAP` environment variable or it can be set on a per-command basis using the `--bootstrap` flag.

Once the `galasactl` tool knows which Galasa service to contact, it needs to be configured to be able to authenticate to that service.
To do that, the Galasa Web UI must be used to allocate a personal access token, which can be passed to the `galasactl` to be used.

Personal access tokens are stored in the `GALASA_TOKEN` property in the `galasactl.properties` file in your Galasa home folder. The `galasactl.properties` file is created when you run the `galasa local init` command. Setting the `GALASA_TOKEN` property in this file with a valid token value allows the galasactl tool to access and communicate with an Ecosystem on behalf of the user.
A personal access tokens is stored in the `GALASA_TOKEN` property in the `galasactl.properties` file in your Galasa home folder, or in the `GALASA_TOKEN` environment variable. The `galasactl.properties` file is created when you run the `galasa local init` command. Setting the `GALASA_TOKEN` property in this file with a valid token value allows the galasactl tool to access and communicate with an Ecosystem on behalf of the user.


If you have [installed your Galasa Ecosystem](../ecosystem/ecosystem-installing-k8s) by using the Galasa Ecosystem Helm chart that is provided with Galasa, you will have access to the Galasa Web UI. To get a value for the `GALASA_TOKEN` property, log into the Galasa Web UI and request a personal access token which can be copied into the `GALASA_TOKEN` property. The instructions on how to do this are displayed in a dialog box in the Galasa Web UI. You can choose to set the token as an environmental variable but the value would not persist across terminals, so is only valid for that session.
If you have [installed your Galasa Ecosystem](../ecosystem/ecosystem-installing-k8s) by using the Galasa Ecosystem Helm chart that is provided with Galasa, you will have access to the Galasa Web UI. To get a value for the `GALASA_TOKEN` property, log into the Galasa Web UI and request a personal access token (using the 'My Settings' page) which can be copied into the `GALASA_TOKEN` property. The instructions on how to do this are displayed in a dialog box in the Galasa Web UI. You can choose to set the token as an environmental variable but the value would not persist across terminals, so is only valid for that session.

## Authentication architecture

Expand All @@ -18,10 +19,13 @@ The following diagram shows the architecture for the authentication process:
![Galasa ecosystem architecture:](ecosystem-cluster-auth.svg)


When a user logs into the Galasa Web UI via their browser, the Web UI contacts the Galasa API server which in turn talks to a Dex server, providing it with the user ID. The Dex server talks to an identity provider, for example GitHub or LDAP, to authenticate that user. If the user is successfully authenticated, the provider returns an access token to the Dex server which sends that token to Galasa API server. The token is then sent to the Galasa Web UI where it is visible to the user. The user can then configure that token into the galasactl command line tool by updating the `GALASA_TOKEN` property in the `galasactl.properties` file. The user can then be authenticated each time the galasactl tool is used to log into a Galasa Ecosystem.
When a user logs into the Galasa Web UI via their browser, the Web UI contacts the Galasa API server which in turn talks to a Dex server, providing it with the user ID. The Dex server talks to an identity provider, for example GitHub or LDAP, to authenticate that user. If the user is successfully authenticated, Dex returns a bearer token to the Galasa API server, which in turn passes the token to the Galasa Web UI. The bearer token is then stored in a cookie by the web browser, to be used in further interactions with the Galasa Web UI until the user logs out of the web application, or the token expires.

Once logged-in to the Web UI, the user can then create a new access token token (using the 'My Settings' page). This provides a secret access token which must be copied from the Web UI panel and made available to the `galasactl` command line tool. The access token can be placed in the `GALASA_TOKEN` property in the `galasactl.properties` file, or the `GALASA_TOKEN` environment variable.

On a successful login, a `bearer-token.json` file is created in the Galasa home directory. This file contains a bearer token that galasactl uses to authenticate requests when communicating with a Galasa Ecosystem. If the bearer token expires, galasactl automatically attempts to re-authenticate with the Galasa Ecosystem using the properties in the `galasactl.properties` file within the Galasa home directory.
The `galasactl` tool will login implicitly when it needs to contact the remote Galasa service. Or the login state can be explicitly controlled using the `galasactl auth login` and `galasactl auth logout` commands.

On a successful login using the `galasactl` tool, the `GALASA_TOKEN` will be used to create a new temporary bearer token, which is stored in the `bearer-tokens` folder in the Galasa home directory. This file contains a bearer token that galasactl uses to authenticate requests when communicating with a Galasa Ecosystem. If the bearer token expires, galasactl automatically attempts to re-authenticate with the Galasa Ecosystem using the configured `GALASA_TOKEN`.


### Logging in to a Galasa Ecosystem using the auth login command
Expand All @@ -31,7 +35,7 @@ You can log in to a Galasa Ecosystem explicitly by using the `galasactl auth log

### Logging out of a Galasa Ecosystem using the auth logout command

To log out of a Galasa Ecosystem using galasactl, you can use the `galasactl auth logout` command. If you run a galasactl command that interacts with an Ecosystem while logged out, galasactl will attempt to automatically log in using the properties in your `galasactl.properties` file within your Galasa home directory.
To log out of a Galasa Ecosystem using galasactl, you can use the `galasactl auth logout` command. If you run a galasactl command that interacts with an Ecosystem while logged out, galasactl will attempt to automatically log again in using the configured `GALASA_TOKEN`.


### Listing personal access tokens
Expand All @@ -51,6 +55,21 @@ Total:2

The returned token list is sorted in creation date order, with the earliest creation date first. The description information matches the description that is provided by the user when creating a new access token from the Galasa Web UI.

You can also get tokens for a specific user

```
> galasactl auth tokens get --user [email protected]
tokenid created(YYYY/MM/DD) user description
09823128318238 2024-02-03 [email protected] Ecosystem1 access
Total:1
```

If you are unsure which user id you are currently using, you can find out with this command:
```
> galasactl users get --id me
id: [email protected]
```

### Revoking personal access tokens

Expand All @@ -59,10 +78,20 @@ If a user moves to a new role, or loses a laptop with their personal access toke
You can retrieve a list of available personal access tokens that have been created, along with their token IDs, by running the `galasactl auth tokens get` command, as described in the previous section.


Run the following command to revoke a personal access token with the token ID `myId`:
Run the following command to revoke a personal access token with the token ID `myId` substituted for the numeric value visible from the `galasactl auth tokens get` command.

```
galasactl auth tokens delete --tokenid {myId}
```

For example:
```
galasactl auth tokens delete --tokenid myId
> galasactl auth tokens get --user [email protected]
tokenid created(YYYY/MM/DD) user description
09823128318238 2024-02-03 [email protected] Ecosystem1 access
Total: 1
> galasactl auth tokens delete --tokenid 09823128318238
```

*Note:* The `galasactl auth tokens delete` command revokes personal access tokens that a user creates through the Galasa Web UI. When a user runs a CLI command that talks to the Ecosystem, the CLI uses the personal access token to get a JSON Web Token (JWT). A JWT is a separate, temporary token that identifies a user and is used in galasactl commands to talk to the API server. JWTs cannot be revoked, but they do expire, so a user can continue to run CLI commands after revoking their personal access token until their JWT expires. You can remove the JWT that is stored on a user's machine instead of having to wait for the JWT to expire, by running the `galasactl auth logout` command on that machine.
Expand Down

0 comments on commit 190bc53

Please sign in to comment.