Skip to content

First sign-in

This page walks you through your first sign-in to the admin console, and the three settings worth checking straight after.

  1. Find the first administrator’s email and password. The wizard’s last message names the email, and the password is here:

    Deployment Where the password is
    Docker Compose GOIABADA_ADMIN_PASSWORD in docker-compose.override.yml
    Native binaries GOIABADA_ADMIN_PASSWORD in goiabada.env
    Kubernetes In the cluster. The wizard’s last message prints the command that reads it, like this one for the namespace goiabada.
    Terminal window
    kubectl get secret goiabada-secrets -n goiabada -o jsonpath='{.data.admin-password}' | base64 -d

    Didn’t use the wizard? They’re the GOIABADA_ADMIN_EMAIL and GOIABADA_ADMIN_PASSWORD you set.

  2. Open the admin console: http://localhost:9091 after the Quickstart, or the admin console URL you gave the wizard.

  3. Click Admin. The admin console sends you to the auth server’s sign-in page.

  4. Enter the email and password, and click Sign in. You’re back in the admin console, on the list of clients.

Your account can manage everything, so give it a second factor. Under Account, open Two-factor authentication, scan the QR code with an authenticator app, and enter your password and the app’s code.

From then on, signing in to the admin console asks for a code from that app as well as your password.

A new installation lets nobody register. Only you create users until you turn on User self registration enabled under Admin, General. Registering then needs email set up, since a new installation also asks people to verify their address.

Accounts people create can manage their own account, including their profile, sessions and consents, but can’t administer Goiabada. See Self-registration.

Goiabada sends email to verify addresses and to reset passwords. Add your SMTP server under Admin, Email - SMTP, and send yourself a test message from there. Turning SMTP enabled off later empties every field on that page, the password included, so note them first if you’ll turn it back on.

The admin console is a client of the auth server, like the apps you’ll connect later. Clicking Admin starts a standard OpenID Connect sign-in: the browser goes to the auth server, you sign in there, and the auth server sends you back to the admin console with an authorization code.

To open the Admin pages, a user needs the authserver:manage permission. The first administrator has it, along with authserver:manage-account, which opens a user’s own Account pages and which every new user gets. A user without authserver:manage who clicks Admin sees an “Unauthorized (403)” page.

The admin console’s client asks for a second factor only from users who have one set up. That’s why your first sign-in needs only a password, and why signing in needs a code too once you turn on two-factor authentication.

The auth server reads GOIABADA_ADMIN_EMAIL and GOIABADA_ADMIN_PASSWORD only on its first start, when it creates the first administrator in an empty database. Changing them later does nothing, so change your password under Account, Change password. Changed them and can’t sign in? See Locked out of the admin console.

The admin console’s home page also links to the auth server’s discovery document, at /.well-known/openid-configuration on the auth server, such as http://localhost:9090/.well-known/openid-configuration. It lists the auth server’s endpoints, scopes and claims, and every OpenID Connect library can configure itself from it.