The agent server is packaged as a Docker image and can be hosted in a variety of cloud services; some examples are given in this public repo: https://github.com/remixlabs/mixer-aws-examples. This quickstart assumes some familiarity with deploying Docker services, and assumes you can use those examples to deploy the mixer image, control its environment variables, and execute a command in the running container.
A fresh mixer server has no workspaces, no content, and no way to authenticate to it. By providing the server an explicit signing key, you will be able to generate tokens for yourself by executing a command in the running container. (You will configure an identity provider for OAuth sign-in later.)
Generate a P-256 key pair:
openssl ecparam -genkey -noout -name prime256v1 |
openssl pkcs8 -topk8 -nocrypt -out server-key.pem
You can provide this to the container either as a file (and pass the --server-key CLI argument) or an environment variable (set MIXER_SERVER_KEY to cat server-key.pem | base64).
Once the server is running with a fixed signing key, you can use a separate invocation of the server binary to generate a token. Execute this command in the running container to obtain an authentication token:
mixer token --user [email protected] --lifetime 2h --base-url https://remix.example.com
This command needs access to the same signing key as the server, again either via --server-key or the MIXER_SERVER_KEY environment variable. The --base-url option must also be the same for the mixer serve and mixer token invocations, since the tokens are tied to a particular host. The lifetime is specified in seconds, minutes, or hours (s, m, or h), with a maximum of 24h.
To be able to create a workspace with this token, the identity should be included in the “workspace creators” setting (either the --workspace-creator option to mixer serve or the WORKSPACE_CREATORS environment variable).
Now that you have a token, you can create a workspace:
export AUTH="Authorization: Bearer ${TOKEN}"
curl -H "$AUTH" ${BASE_URL}/v0/ws --json '{"name": "acme", "settings": {"auth": {"greeting": "Sign in to Remix for Acme"}}}'
The auth option isn’t required, but setting it means this will be an “auth workspace”: a workspace that can be configured with an identity provider so that it can issue tokens. Creating a workspace makes you an admin of that workspace.
So far, the only way to authenticate to the server is to generate tokens by directly executing a command in the container. Once you set up an identity provider, you and others can use it to sign in to this workspace. Any OAuth 2.0 provider is supported.
You will first need to create an OAuth configuration in your identity provider’s console; for example, see Google’s documentation for doing this here. You will probably need to register a “callback” or “redirect” URL: this will be ${BASE_URL}/v1/auth/callback.
To register the provider with mixer, post a configuration record like this to /v1/ws/{ws}/auth/providers:
curl -H "$AUTH" https://remix.example.com/v1/ws/acme/auth/providers --json '
{
"auth_url": "https://accounts.google.com/o/oauth2/v2/auth",
"client_id": "abc123",
"client_secret": "hunter22",
"name": "google",
"scopes": [
"https://www.googleapis.com/auth/userinfo.email",
"https://www.googleapis.com/auth/userinfo.profile"
],
"token_url": "https://oauth2.googleapis.com/token",
"userinfo_url": "https://www.googleapis.com/oauth2/v3/userinfo"
}'
This example would implement Google OAuth (with real client ID and secret substituted). For the full set of options, see the OpenAPI docs for this endpoint (https://agt.remixlabs.com/v1/swagger/#/auth/create_provider or your own hosted version).