Skip to main content
Version: v0.25.0 (Latest)

Provisioning and Onboarding

This page takes a freshly installed EDK deployment to a working platform with its first tenant. There are two paths to the same end state. The interactive path uses the onboarding web interface and the admin UI; the scripted path uses the provision script from the deployment repository. Pick whichever fits how you operate. Both produce an identical result: an active license, a closed setup gate, an operator account that can sign in at https://platform.<base-domain>/admin-console, and a tenant with an issuer, a verifier, and an authorization server bound to public endpoints.

The deployment being onboarded must use the published enterprise images from the private Nexus Docker repository nexus.sphereon.com/edk-docker. Kubernetes deployments install the edk-enterprise chart from Sphereon's private Nexus Helm repository https://nexus.sphereon.com/repository/edk-helm; the enterprise images are private Nexus artifacts only.

Before starting, complete one of the install guides so the stack is running:

On the local base domain a tenant is reachable at <tenant>.saas.localtest.me, with the operator at platform.saas.localtest.me.

Local Equals Production​

The steps below are the same locally and in production. Only the base domain and the TLS termination point differ. A platform onboarded at https://platform.saas.localtest.me follows the exact same setup, tenant creation, and public-endpoint binding as one onboarded at https://platform.example.com. Treat the local run as a faithful rehearsal of the production onboarding.

Path 1: Interactive​

The interactive path is the recommended one when a person is installing or evaluating the platform.

  1. Open the operator host in a browser: https://platform.<base-domain> (locally https://platform.saas.localtest.me).
  2. Complete first-run setup in the onboarding web interface: establish the license (generate a license request or import an issued token) and create the first platform operator account. Both must complete before the deployment is usable; the setup gate then closes. The full first-run contract and the onboarding paths are covered in Platform onboarding.
  3. Sign in as the platform operator through the platform authorization server. After the license is active and the operator account exists, the normal entry point is https://platform.<base-domain>/admin-console. See Operator sign-in.
  4. Create the tenant in the admin UI. Registering a tenant gives it routing, isolation, and an owner.
  5. For the tenant, configure its services and bind a public endpoint for the issuer, the verifier, and the authorization server, so the tenant advertises and serves them at its own host. The binding step is covered in Instance deployment, and the per-service configuration in Roles and Topology.

After the tenant's endpoints are bound, the platform is onboarded. The tenant resolves from its host and serves its protocol surface on the single port. Repeat the tenant steps for each additional tenant.

Path 2: Scripted​

The scripted path suits a deployment that is CI-driven or managed by your own installer. It uses the provision script from the Enterprise Development Kit Deployment repository (scripts/provision.ps1 on Windows, scripts/provision.sh elsewhere), which calls the published REST APIs directly against the running deployment.

  1. Fill in the Postman customer environment file (postman/EDK-Enterprise-Deployment.customer.postman_environment.json) with the service URLs, the operator credentials, the operator sign-in parameters, the tenant name and slug, the tenant public hosts, and your license token. The script reads its configuration from this file.

  2. Run the provision script:

    scripts/provision.sh

    On Windows, run scripts\provision.ps1. The script waits for the KMS, DID, AS, issuer, and verifier services to report healthy, then runs platform setup only if the setup gate is still open (bootstrapping the operator account and installing the license token), signs the operator in through the authorization-code flow with PKCE, registers the tenant, and binds the tenant's issuer, verifier, and authorization server public endpoints. Setup is idempotent: when the gate is already closed, the script skips it and continues, so it is safe to re-run.

  3. Override values per run with the flags: --env-file selects a different environment file, --tenant-name and --tenant-slug set the tenant, and --skip-setup skips platform setup when the platform is already initialized. On Windows the equivalents are -EnvFile, -TenantName, -TenantSlug, and -SkipSetup.

  4. When the run finishes, the script prints the operator console URL, the tenant id, and the tenant's issuer metadata, AS metadata, and did.json URLs so you can confirm the tenant is live.

The Postman collection and the customer environment ship in the deployment repository under postman/ and are also available from the walkthrough downloads page. The collection walks the same onboarding flow request by request, plus the later keys, credential design, status list, issuance, and verification steps. The request and response examples for every call are shown across the Enterprise deployment walkthrough; for the wire shapes, follow the REST API reference links on each page rather than hand-copying request bodies.

Verifying the End State​

Whichever path you took, the deployment is onboarded when all of the following hold:

  • The license is active and the setup gate is closed; the anonymous setup API returns 404.
  • The platform operator can sign in at https://platform.<base-domain>/admin-console and call the Platform Admin API at /api/platform/admin/v1.
  • The tenant resolves from its host and has a bound issuer, verifier, and authorization server public endpoint.

From here, exercise credential issuance and verification per tenant. The Enterprise deployment walkthrough covers keys and did:web, credential designs, status lists, issuance over OID4VCI, DCQL queries, and verification over OID4VP.

Next Steps​