Architecture

This API used one database per service pattern

Service Details

User

This service handle /v1/account endpoint. This service deal with account related stuff

Games

This service handle /v1/games endpoint. This service handle user game collections

Auth

This service handle /v1/auth endpoint. This service handle client authorization to access specific endpoint

Session

This service handle /v1/sessionendpoint. This service is a middleware between client and session manager.

Certificate Manager

This service handle certificate distribution to all the service above for internal HTTPS communications and internal service authentication.

Session Manager

This is the service that handle VM creation automation.

Database Schema

Games

This the table schema of games service database.

There are three tables; games, storage_location, and user_games_collections. games is a table that store all supported games. This table hold information on the name of the games, the game icon, and the display picture (icon but big), and storage_id which point to storage_location table. storage_location table give information on to retrieve game from the storage location. This information include the protocol, ip/host, port (if needed), and location or endpoint.

Session

In the session database, there are three tables, session, session_host, and session_metadata. Session is for storing the request status of the session. The status is of type ENUM called status. See the session details on endpoint for details regarding the possible value of the status. The session id using UUIDv7 stored in bytes format.

In session_metadata table, there are data for storing extra information regarding the session. That include the creation time the username that create the session, and the game that are played

session_host table store information regarding the VM that hosted the session. That include the address of the VM and the zero-tier networkid.

Flowchart

Steam Link

To be able to use the game service, first, the user need to link their steam account.

Upon accessing /v1/middleware/steam/{username}, the page will be redirected to the steam login page

Upon successful login, the user will be redirected to the success_redirect that were assigned in the query parameter. If success_redirect query parameter is not set, then the middleware will use it's default success redirect.

If any error occured during this process, the middleware will redirect user to fail_redirect that were also set in the query parameter. It will use default fail redirect when the query parameter is not set.

Default redirect only show a JSON message to the user, below is the example on default failure redirect

Session Creation

Important

For internal only endpoint, mTLS (mutual TLS) is required, the API won't accept any request with invalid client certificate. If you are developing service that need access to internal endpoint, please refer the mTLS section on this documents.

Mutual TLS

The API protected internal endpoint by using mutual TLS . In Mutual TLS, each party must provide a valid certificate. Valid certificate in this case, is a certificate that were signed by the internal PKI.

Info

Please refer to endpoint documentation for details on which endpoint is internal only

In order for your application to have a valid certificate, create a certificate sign request (csr) file, and send that request to the PKI API (Certificate - Manager). Then add the CA of the certificate manager to the trusted certificate, either on OS level or application level. Below is an example on how to do it on Linux (openssl and curl required): 1. Create a RSA private key (2048 bit)

linux

$ openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048

2. Create a CSR (Certificate Sign Request) File

linux

$ export UNIT="/C=${COUNTRY}/ST=${STATE}/L=${LOCALITY}/O=${ORGANIZATION}/OU=${ORG_UNIT}/CN=${COMMON_NAME}"
$ export SUBJECT_ALT_NAME="DNS.1:${SERVICE_NAME},IP.1:${HOST"

$ openssl req -new \
    -key private_key.pem \
    -subj "${UNIT}" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=${SUBJECT_ALT_NAME}")) \
    -out $CSR_FILE_PATH

Info

I don't know if <(printf "\n[SAN]\nsubjectAltName=${SUBJECT_ALT_NAME}") available on Windows.

Please change the placehoder (or add environment variables) with the proper values.

3. Send the csr to the cert manager api
   linux

   $ curl -k https://$PKI_HOST/certificate -o cert/root-ca.crt
   

   This will save the signed CA for your service in cert/root-ca.crt. Use this in your application.

Info

PKI host is 34.101.181.190:5500

4. Get the Root Certificate

   linux

   $ curl -k -v -F "csr=@${CSR_FILE_PATH}" https://$PKI_HOST/certificate/sign -o $CERT_FILE_PATH
   

   This will save the Root CA in CERT_FILE_PATH.

5. (Optional) Encrypt your private key in PKCS8 Format

   linux

   $ openssl pkcs8 -topk8 -inform PEM -outform PEM -in private_key.pem -out $PRIVATE_KEY_PATH -passout file:/tmp/passphrase
   

   This will encrypt the private key using passphrase specified in the file /tmp/passphrase.

Now, when you want to create a request, provide the certificate. if you create a valid certificate, you won't get access_denied 403 Unauthroized error.