Security AWS

Gravitee Access Management 4.13.2 on AWS User Guide

| Product: Gravitee Access Management 4.13.2 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and using the Gravitee Access Management 4.13.2 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg identity, secrets and PKI listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Gravitee Access Management (AM) is an open source identity and access management server. It is an OAuth 2.0 authorization server and OpenID Connect provider: you create security domains (each one is an independent identity provider with its own issuer, users, applications and signing keys), register applications (OAuth/OIDC clients: web apps, single-page apps, mobile apps, services), manage users and external identity providers, and add single sign-on and multi-factor authentication to your own applications. A web management console and a REST management API configure it; a separate gateway serves the OAuth 2 / OpenID Connect endpoints (authorize, token, userinfo, discovery, JWKS and the hosted login pages) to your applications.

The cloudimg image is a hardened, ready-to-use Gravitee AM server:

  • The open source edition only. The official Gravitee AM 4.13.2 images also carry Gravitee Enterprise Edition plugins (licence-gated, private source). cloudimg removes them: the management API and gateway images on the AMI are the official images with only those plugin archives taken out, and the list of what was removed is in /usr/share/doc/cloudimg-gravitee-am/. No licence key is used or needed.
  • Pinned and preloaded. The management API, gateway and PostgreSQL 16 images are pinned by digest and stored on the AMI, so a new instance never downloads them. The console's static files are served by nginx. Docker CE comes from Docker's own repository with its signing key pinned by fingerprint.
  • HTTPS from the first boot. nginx serves the management console and API on 443 and the OAuth 2 / OpenID Connect gateway on 8443, with a certificate generated on your instance (an end-entity certificate, not a certificate authority). Port 80 redirects to HTTPS. The instance's name is set from its own EC2 public DNS name at first boot; you can change it to your own domain.
  • No default login. First boot creates one console administrator, admin, with a random password unique to your instance. The upstream default admin / adminadmin account does not exist.
  • Per-instance secrets. The PostgreSQL password, the management API and gateway token-signing secrets, the gateway's CSRF secret and the default certificate's keystore password are all generated on first boot. They are in configuration files only root and the service account can read, mounted read-only into the containers, so they are not shown by docker inspect, on any command line or in any process environment.
  • Safe defaults for new security domains. Self-registration and OAuth dynamic client registration are off for every new security domain; you turn them on per domain if you need them. No mail server is configured.
  • Back ends on the loopback address only. The management API and gateway containers are published on 127.0.0.1 only; PostgreSQL is on an internal Docker network with no published port at all. The client address the applications see is the real TCP peer, never a header a client can forge.
  • Locked-down containers. Every container runs as a non-root user with a read-only root filesystem, no Linux capabilities, no-new-privileges, memory and process limits and no core dumps.
  • Metadata service blocked. Docker, containerd, every container, nginx and the Gravitee AM services are blocked from the EC2 instance metadata service (an identity provider or JWKS URL pointing at it fails), and the AMI requires IMDSv2.
  • Its own data volume. The PostgreSQL database lives on a separate 20 GiB EBS volume mounted at /var/lib/gravitee-am, which you can resize on its own. It ships empty: the database is created on your first boot.
  • Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on (for Ubuntu and for Docker CE).

What is on the image: Gravitee Access Management 4.13.2 (management API, gateway and console; Apache-2.0), PostgreSQL 16.15 (Alpine), the PostgreSQL JDBC 42.7.14 and R2DBC 1.0.9 drivers, Docker CE, nginx from Ubuntu 24.04, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large (2 vCPUs, 8 GiB)

Prerequisites

  • An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet.
  • A security group that allows TCP 22 (SSH) from your own networks only, TCP 443 (the management console and API) from your administrators, TCP 8443 (the OAuth 2 / OpenID Connect gateway) from wherever your applications and their users are, and TCP 80 (redirects to HTTPS).
  • An instance with at least 8 GiB of memory: the management API and the gateway are two Java services (m5.large, t3.large or larger).
  • For production, a DNS name you control (for example am.example.com) and, ideally, a certificate from a certificate authority. Until then the instance uses its EC2 public DNS name with its own self-signed certificate.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Gravitee Access Management 4.13.2 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair, and a security group as above. Keep the second (20 GiB) volume: it holds the database.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=gravitee-am}]'

First boot takes about two minutes after the instance is running: it creates the database, starts the management API and the gateway once to create their schemas, creates your administrator and the certificate, and then starts the stack.

Step 2: Connect to your instance

Operating system SSH user
Ubuntu 24.04 ubuntu 
ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

systemctl is-active gravitee-am-firstboot docker gravitee-am-postgres gravitee-am-management-api gravitee-am-gateway nginx

active
active
active
active
active
active

The health check signs nothing in; it asks the console, the management API and the gateway for a page over HTTPS through nginx, verifying the instance's certificate:

sudo gravitee-am-health

PRIMARY_HEALTH_OK console=200 management-api=401(auth required) gateway=404(no domain yet)

Only SSH, HTTP, HTTPS (443) and the gateway port (8443) are public. The management API (8093) and gateway (8092) containers listen on the loopback address only, and PostgreSQL has no listener on the host at all:

sudo ss -tln | grep -E ':(22|80|443|8443|8092|8093|5432) '

LISTEN 0      511          0.0.0.0:443       0.0.0.0:*
LISTEN 0      4096         0.0.0.0:22        0.0.0.0:*
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*
LISTEN 0      511          0.0.0.0:8443      0.0.0.0:*
LISTEN 0      4096       127.0.0.1:8092      0.0.0.0:*
LISTEN 0      4096       127.0.0.1:8093      0.0.0.0:*
LISTEN 0      511             [::]:443          [::]:*
LISTEN 0      4096            [::]:22           [::]:*
LISTEN 0      511             [::]:80           [::]:*
LISTEN 0      511             [::]:8443         [::]:*

Step 4: Read the administrator login and the certificate fingerprint

sudo cat /root/gravitee-am-credentials.txt

The file (root only, mode 0600) gives the console and gateway addresses, the administrator's user name and password, and the SHA-256 fingerprint of the instance's certificate:

# Gravitee Access Management 4.13.2 - written on first boot by gravitee-am-firstboot.service. Unique to this instance.
GRAVITEE_AM_CONSOLE=https://ec2-13-217-163-67.compute-1.amazonaws.com/
GRAVITEE_AM_GATEWAY=https://ec2-13-217-163-67.compute-1.amazonaws.com:8443/
GRAVITEE_AM_ADMIN_USERNAME=admin
GRAVITEE_AM_ADMIN_PASSWORD=<per-instance password>
GRAVITEE_AM_TLS_SHA256=D7:3D:9C:DA:...:(64 hex digits in pairs)

# Sign in to the management console at GRAVITEE_AM_CONSOLE as "admin" with GRAVITEE_AM_ADMIN_PASSWORD (the only console
# account; the upstream default admin/adminadmin does not exist). Rotate it: sudo gravitee-am-admin-password rotate
# Each security domain you create is served by the gateway at GRAVITEE_AM_GATEWAY<domain-path>/, e.g. discovery:
#   ec2-13-217-163-67.compute-1.amazonaws.com:8443/<domain-path>/oidc/.well-known/openid-configuration
# Self-registration and dynamic client registration are OFF for new security domains (turn them on per domain).
# No mail server is configured (password reset / verification e-mails need your SMTP settings).
# The certificate is self-signed and unique to this instance: compare its SHA-256 fingerprint (above) with the one your
# browser shows, or install a CA-issued certificate. Do not add it to a trust store.
# Your own name (point DNS at this instance first):  sudo gravitee-am-set-hostname am.example.com
# User guide: https://www.cloudimg.co.uk/guides/gravitee-access-management-4-13-2-on-ubuntu-24-04-aws/

Your browser will warn that the certificate is not trusted, because it was made on your instance. Compare the SHA-256 fingerprint the browser shows with GRAVITEE_AM_TLS_SHA256 before you sign in (or use your own CA-issued certificate, below). Do not add the certificate to a trust store. You can also read it from the certificate itself:

openssl x509 -in /etc/ssl/gravitee-am/gravitee-am.crt -noout -subject -fingerprint -sha256 -ext basicConstraints,subjectAltName

subject=CN = ec2-13-217-163-67.compute-1.amazonaws.com, O = cloudimg
sha256 Fingerprint=D7:3D:9C:DA:...:98:FE:29:0A
X509v3 Subject Alternative Name: 
    DNS:ec2-13-217-163-67.compute-1.amazonaws.com, IP Address:13.217.163.67, IP Address:172.31.89.127, DNS:localhost, IP Address:127.0.0.1
X509v3 Basic Constraints: critical
    CA:FALSE

Step 5: Sign in to the management console

Browse to the GRAVITEE_AM_CONSOLE address, https://<public-dns-name>/, check the certificate fingerprint, and sign in as admin with the password from the credentials file. Use the DNS name, not the IP address: nginx answers only for the instance's configured name, and an address-only request is redirected to it.

The Gravitee AM console sign-in page, served over HTTPS

The upstream default admin / adminadmin is refused, through the console and the API alike. From the instance, with your password read from the root-only file into a private temporary file (it never appears on a command line):

umask 077; T=$(mktemp -d)
sudo sed -n 's/^GRAVITEE_AM_ADMIN_PASSWORD=//p' /root/gravitee-am-credentials.txt | tr -d '\n' | sed 's/^/admin:/' | base64 -w0 | sed 's/^/Authorization: Basic /' > "$T/basic"
D=$(sudo sed -n 's#^GRAVITEE_AM_CONSOLE=https://\([^/]*\)/#\1#p' /root/gravitee-am-credentials.txt)
CA=/etc/ssl/gravitee-am/gravitee-am.crt
curl -s --cacert $CA -o /dev/null -w 'administrator:      HTTP %{http_code}\n' -H @"$T/basic" -X POST "https://$D/management/auth/token"
curl -s --cacert $CA -o /dev/null -w 'admin / adminadmin: HTTP %{http_code}\n' -u admin:adminadmin -X POST "https://$D/management/auth/token"
curl -s --cacert $CA -o /dev/null -w 'no credentials:     HTTP %{http_code}\n' "https://$D/management/organizations/DEFAULT/environments/DEFAULT/domains"
rm -rf "$T"

administrator:      HTTP 200
admin / adminadmin: HTTP 401
no credentials:     HTTP 401

Step 6: Create a security domain, an application and a user

A security domain is one OpenID Connect provider with its own issuer, users and applications. You can create everything below in the console (Security domains, then Create, then Applications and Users in the domain); the same steps with the management API, from the instance, look like this. They create a domain my-company, a web application my-web-app that must use PKCE, and a user jane. The application's secret and the user's password are generated here and written to a root-only file; nothing secret is printed:

umask 077; T=$(mktemp -d)
D=$(sudo sed -n 's#^GRAVITEE_AM_CONSOLE=https://\([^/]*\)/#\1#p' /root/gravitee-am-credentials.txt)
CA=/etc/ssl/gravitee-am/gravitee-am.crt
sudo sed -n 's/^GRAVITEE_AM_ADMIN_PASSWORD=//p' /root/gravitee-am-credentials.txt | tr -d '\n' | sed 's/^/admin:/' | base64 -w0 | sed 's/^/Authorization: Basic /' > "$T/basic"
curl -s --cacert $CA -H @"$T/basic" -X POST "https://$D/management/auth/token" | jq -r '"Authorization: Bearer " + .access_token' > "$T/auth"
API="https://$D/management/organizations/DEFAULT/environments/DEFAULT"
DOM=$(curl -s --cacert $CA -H @"$T/auth" -H 'Content-Type: application/json' -d '{"name":"my-company","description":"My first security domain","dataPlaneId":"default"}' "$API/domains")
DID=$(jq -r .id <<<"$DOM"); DPATH=$(jq -r .path <<<"$DOM")
curl -s --cacert $CA -H @"$T/auth" -H 'Content-Type: application/json' -X PATCH -d '{"enabled":true}' -o /dev/null "$API/domains/$DID"
IDP=$(curl -s --cacert $CA -H @"$T/auth" "$API/domains/$DID/identities" | jq -r '.[0].id')
UPW="Jane-$(openssl rand -hex 12)"
jq -n --arg pw "$UPW" --arg idp "$IDP" '{username:"jane",password:$pw,firstName:"Jane",lastName:"Doe",email:"jane@example.com",source:$idp,preRegistration:false}' > "$T/user.json"
curl -s --cacert $CA -H @"$T/auth" -H 'Content-Type: application/json' -d @"$T/user.json" -o /dev/null -w 'user jane: HTTP %{http_code}\n' "$API/domains/$DID/users"
APP=$(curl -s --cacert $CA -H @"$T/auth" -H 'Content-Type: application/json' -d '{"name":"my-web-app","type":"WEB","redirectUris":["https://client.example.org/callback"]}' "$API/domains/$DID/applications")
AID=$(jq -r .id <<<"$APP"); CID=$(jq -r .settings.oauth.clientId <<<"$APP")
jq -n --arg idp "$IDP" '{identityProviders:[{identity:$idp,priority:0}],settings:{oauth:{grantTypes:["authorization_code"],responseTypes:["code"],forcePKCE:true,redirectUris:["https://client.example.org/callback"],scopeSettings:[{scope:"openid",defaultScope:true},{scope:"profile"},{scope:"email"}]},advanced:{skipConsent:true}}}' > "$T/app.json"
curl -s --cacert $CA -H @"$T/auth" -H 'Content-Type: application/json' -X PATCH -d @"$T/app.json" -o /dev/null -w 'application my-web-app: HTTP %{http_code}\n' "$API/domains/$DID/applications/$AID"
{ echo "DOMAIN_PATH=$DPATH"; echo "CLIENT_ID=$CID"; echo "CLIENT_SECRET=$(jq -r .settings.oauth.clientSecret <<<"$APP")"; echo "USER=jane"; echo "USER_PASSWORD=$UPW"; } | sudo tee /root/gravitee-am-my-company.txt > /dev/null
sudo chmod 600 /root/gravitee-am-my-company.txt
echo "domain my-company: path $DPATH, client id $CID (secret and user password in /root/gravitee-am-my-company.txt)"
rm -rf "$T"

user jane: HTTP 201
application my-web-app: HTTP 200
domain my-company: path /my-company, client id 8d8ffa37-70af-4d2d-8ffa-3770af3d2d69 (secret and user password in /root/gravitee-am-my-company.txt)

The domain's OpenID Connect discovery document is served by the gateway on port 8443. Give the gateway a few seconds to load a new domain:

D=$(sudo sed -n 's#^GRAVITEE_AM_CONSOLE=https://\([^/]*\)/#\1#p' /root/gravitee-am-credentials.txt)
P=$(sudo sed -n 's/^DOMAIN_PATH=//p' /root/gravitee-am-my-company.txt)
for i in $(seq 1 30); do curl -s --cacert /etc/ssl/gravitee-am/gravitee-am.crt -o /dev/null -f "https://$D:8443$P/oidc/.well-known/openid-configuration" && break; sleep 3; done
curl -s --cacert /etc/ssl/gravitee-am/gravitee-am.crt "https://$D:8443$P/oidc/.well-known/openid-configuration" | jq '{issuer, authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, code_challenge_methods_supported}'

{
  "issuer": "https://ec2-13-217-163-67.compute-1.amazonaws.com:8443/my-company/oidc",
  "authorization_endpoint": "https://ec2-13-217-163-67.compute-1.amazonaws.com:8443/my-company/oauth/authorize",
  "token_endpoint": "https://ec2-13-217-163-67.compute-1.amazonaws.com:8443/my-company/oauth/token",
  "userinfo_endpoint": "https://ec2-13-217-163-67.compute-1.amazonaws.com:8443/my-company/oidc/userinfo",
  "jwks_uri": "https://ec2-13-217-163-67.compute-1.amazonaws.com:8443/my-company/oidc/.well-known/jwks.json",
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

In the console, the domain now lists the application and the user:

The security domains list in the Gravitee AM console

The my-web-app OAuth 2 / OpenID Connect application in the my-company domain

The user jane in the my-company domain

Step 7: Sign a user in with OpenID Connect (authorization code + PKCE)

Your application sends the user's browser to the domain's authorization endpoint on port 8443, and the gateway shows its hosted sign-in page (there is no "sign up" link: self-registration is off):

The gateway's hosted sign-in page for the my-company domain

The image includes an end-to-end check that runs the whole flow the way an application does, over HTTPS through nginx with the instance's certificate verified: it creates a temporary security domain, a web application that requires PKCE and a user, signs the user in on the gateway's login page, exchanges the authorization code for tokens, calls userinfo, checks that a second use of the same code, a request without PKCE and a wrong password are refused, that anonymous dynamic client registration is refused and that self-registration is off, and then deletes the temporary domain. It prints no token or secret:

sudo gravitee-am-cred-roundtrip.sh

GRAVITEE_AM_ROUNDTRIP_OK admin=200 wrong-default-empty=401 dcr=403 self-registration=refused no-pkce=invalid_request wrong-user-password=refused flow=login>code>token>userinfo pkce=S256-required code-reuse=invalid_grant id_token=RS256 issuer=pinned

Step 8: Check the security defaults

Anonymous OAuth dynamic client registration (RFC 7591) and self-registration are refused on every new domain:

D=$(sudo sed -n 's#^GRAVITEE_AM_CONSOLE=https://\([^/]*\)/#\1#p' /root/gravitee-am-credentials.txt)
P=$(sudo sed -n 's/^DOMAIN_PATH=//p' /root/gravitee-am-my-company.txt)
C=$(sudo sed -n 's/^CLIENT_ID=//p' /root/gravitee-am-my-company.txt)
curl -s --cacert /etc/ssl/gravitee-am/gravitee-am.crt -o /dev/null -w 'anonymous client registration: HTTP %{http_code}\n' -H 'Content-Type: application/json' -d '{"redirect_uris":["https://attacker.example/cb"],"client_name":"probe"}' "https://$D:8443$P/oidc/register"
if curl -s --cacert /etc/ssl/gravitee-am/gravitee-am.crt -L "https://$D:8443$P/register?client_id=$C" | grep -q 'name="email"'; then echo 'self-registration: form served'; else echo 'self-registration: refused (error page)'; fi

anonymous client registration: HTTP 403
self-registration: refused (error page)

The services and every container are blocked from the instance metadata service. From inside the gateway container, as its own user, a request to the metadata address times out while a request to the gateway itself answers (with a 404, as no domain lives at its root):

sudo docker exec gam-gateway sh -c 'wget -q -T 5 -O /dev/null http://169.254.169.254/latest/meta-data/ 2>/dev/null && echo "metadata: reachable" || echo "metadata: blocked"; echo "gateway control:$(wget -S -q -T 5 -O /dev/null http://127.0.0.1:8092/ 2>&1 | head -1)"'

metadata: blocked
gateway control:  HTTP/1.1 404 Not Found

The containers run unprivileged, and no secret is in any container's configuration: the environment holds only paths, locale and Java memory settings (the secrets are in root-owned files mounted read-only):

sudo docker inspect gam-management-api gam-gateway gam-postgres --format '{{.Name}} user={{.Config.User}} readonly={{.HostConfig.ReadonlyRootfs}} capdrop={{.HostConfig.CapDrop}} privileged={{.HostConfig.Privileged}}'
sudo docker inspect gam-management-api gam-gateway gam-postgres --format '{{range .Config.Env}}{{println .}}{{end}}' | cut -d= -f1 | grep . | sort -u | tr '\n' ' '; echo

/gam-management-api user=997:986 readonly=true capdrop=[ALL] privileged=false
/gam-gateway user=997:986 readonly=true capdrop=[ALL] privileged=false
/gam-postgres user=70:70 readonly=true capdrop=[ALL] privileged=false
DOCKER_PG_LLVM_DEPS GIO_MAX_MEM GIO_MIN_MEM GOSU_VERSION GRAVITEE_AM_HOME JAVA_HOME JAVA_OPTS LANG LANGUAGE LC_ALL NO_COLOR PATH PGDATA PG_MAJOR PG_SHA256 PG_VERSION POSTGRES_HOST_AUTH_METHOD POSTGRES_INITDB_ARGS POSTGRES_USER

Step 9: Use your own domain name and certificate

Point a DNS record (for example am.example.com) at the instance's public IP address, then set the name. This updates nginx, the console and API, the gateway's issuer and the links in the credentials file, and makes a new self-signed certificate for the name:

sudo gravitee-am-set-hostname am.example.com

Security domains you created before the change keep their users and applications; their issuer follows the new name (https://am.example.com:8443/<domain-path>/oidc), so update the issuer and redirect URLs your applications use. To use a CA-issued certificate instead, replace /etc/ssl/gravitee-am/gravitee-am.crt (full chain) and /etc/ssl/gravitee-am/gravitee-am.key (the key, mode 0600) and run sudo systemctl reload nginx. The current name and certificate:

sudo gravitee-am-set-hostname --show

name:         ec2-13-217-163-67.compute-1.amazonaws.com
console:      https://ec2-13-217-163-67.compute-1.amazonaws.com/
gateway:      https://ec2-13-217-163-67.compute-1.amazonaws.com:8443/<domain>/oidc/.well-known/openid-configuration
also served:  ec2-13-217-163-67.compute-1.amazonaws.com 13.217.163.67 172.31.89.127
certificate:  SHA-256 D7:3D:9C:DA:...:98:FE:29:0A

Step 10: Change the administrator password

The administrator is an account defined in the management API's configuration (only its bcrypt hash is stored), so its password is changed with the image's helper, which generates a new random password, restarts the management API and writes the new password to /root/gravitee-am-credentials.txt:

sudo gravitee-am-admin-password rotate

Maintenance

  • Logs: every service logs to the journal: sudo journalctl -u gravitee-am-gateway -u gravitee-am-management-api -n 50.
  • Restart: sudo systemctl restart gravitee-am-management-api gravitee-am-gateway. The services start in order (PostgreSQL, the management API, the gateway, nginx) at every boot.
  • Database volume: the database lives on its own EBS volume:
df -h /var/lib/gravitee-am

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1     20G   69M   19G   1% /var/lib/gravitee-am
  • Backups: take EBS snapshots of the data volume, or dump the database (the dump contains your users' password hashes and client secrets: keep it private):
umask 077; sudo docker exec -u 70 gam-postgres pg_dump -U postgres -d gravitee_am -Fc > ~/gravitee-am-backup.dump && ls -l ~/gravitee-am-backup.dump | awk '{print $1, $5, $9}'

-rw------- 277764 /home/ubuntu/gravitee-am-backup.dump
  • Updates: Ubuntu and Docker CE security updates install automatically (reboot for a new kernel). Gravitee AM itself is updated by moving to a newer version of this listing: launch the new version and move your data, or follow Gravitee's upgrade notes.
  • Memory: the management API runs with a 768 MiB heap and the gateway with 1 GiB; together with PostgreSQL the stack uses about 2.2 GiB of the m5.large's 8 GiB.

Security notes

  • Only open 443 to your administrators; 8443 is the port your applications and their users need.
  • Self-registration, dynamic client registration and e-mail are off for new domains. If you turn self-registration on for a domain, configure a mail server first (domain Settings, Email) so verification and password-reset messages work.
  • External identity providers, JWKS URLs and HTTP callouts you configure are fetched from the instance; the instance metadata service is never reachable from them.
  • Known advisories at build time (30 October 2026): the Alpine packages in all three images have none. The Java libraries that Gravitee AM 4.13.2 bundles carry published advisories (Spring Web MVC, Netty, FreeMarker, Jackson, Guava, Commons BeanUtils, jsoup, Micrometer) that the upstream release has not yet updated; none is reachable in this configuration: the affected features (XSLT views, TLS or HTTP/2 inside Netty, FreeMarker localized lookup, metrics, untrusted Java deserialization, polymorphic JSON) are not used or are switched off, nginx terminates TLS, and the remaining JSON-parsing issue needs an authenticated request because dynamic client registration and SCIM are off (nginx also caps gateway request bodies at 256 KB). Take the next Gravitee AM version from this listing when it ships.
  • The licence texts, the source pointer and the lists of the Enterprise Edition plugins that were removed are in /usr/share/doc/cloudimg-gravitee-am/.

Support

cloudimg provides 24/7 support for this image by e-mail at support@cloudimg.co.uk. Gravitee Access Management documentation: https://documentation.gravitee.io/am.