PingOne Advanced Identity Cloud
Services authenticate with an Advanced Identity Cloud client whose id is your workspace id. One identity per realm per workspace.
Services authenticate with an Advanced Identity Cloud client whose id is your workspace id. One identity per realm per workspace.
Identity proof
The token has to come from https://openam-acme.forgeblocks.com:443/am/oauth2/realms/root/realms/alpha, and its subname claim has to hold YOUR_WORKSPACE_ID, which we build from your workspace id. We compare that claim byte for byte, with no wildcards.
That value is the same for every identity on the issuer, so your workspace connects one per issuer. A second connect on it is refused until you revoke the first.
subname is matched rather than sub, which on this platform does not name the workload in a form you can pin.
Every token also has to name your workspace as its audience. Ask for this audience and no other. A token requested for two audiences fails every exchange.
Console fields
| Field | Example | Advanced | What it pins |
|---|---|---|---|
| Issuer URL | https://openam-acme.forgeblocks.com:443/am/oauth2/realms/root/realms/alpha | no | The issuer of your realm's /.well-known/openid-configuration, :443 included. Its client id is your workspace id, so this is your one identity per realm here. |
The console also asks which project and environment this identity reaches and which role it gets, with the credential lifetime behind Advanced.
Trust
Built from the example answers above:
| What | Value |
|---|---|
| Issuer | https://openam-acme.forgeblocks.com:443/am/oauth2/realms/root/realms/alpha |
| Claim compared | subname |
| Subject | YOUR_WORKSPACE_ID |
| Identity name | pingaic-openam-acme-forgeblocks-com-alpha |
We name the identity for you, so the form never asks for one.
Console snippet
# Advanced Identity Cloud, once, in the realm: a custom OAuth2 client with
# Client ID = YOUR_WORKSPACE_ID
# Grant types = Client Credentials only, token endpoint auth method client_secret_post.
# OAuth2 Provider Overrides: Enable OAuth2 Provider Overrides = on,
# Use Client-Side Access & Refresh Tokens = on. Client-side is already the default; the
# override keeps this client on it whatever the realm is set to.
# The realm's OAuth2 Provider → Advanced → OAuth2 Token Signing Algorithm = RS256, since the
# default signs with a demo key. This one has no per-client override: it changes the signature on
# every client's access tokens in the realm. Check what your other resource servers verify first,
# or use a realm dedicated to Penv.
# We know this client only by its id, which is your workspace id, so:
# use the client for Penv alone: every token it gets names your workspace, wherever it is sent;
# allow it client credentials and no other grant, so nobody signs in through it;
# one identity per realm per workspace, since the client id is now taken.
# Ask for this audience and no other. A token requested for two audiences fails every exchange.
# $AIC_CLIENT_SECRET is this client's own secret, already on the machine.
URL=$(curl -fsS "<ISSUER>/.well-known/openid-configuration" | jq -r .token_endpoint)
T=$(jq -jn --arg id "YOUR_WORKSPACE_ID" \
'"grant_type=client_credentials&client_id=\($id|@uri)&client_secret=\((env.AIC_CLIENT_SECRET // "" | if . == "" then error("AIC_CLIENT_SECRET is not set") else . end)|@uri)"' \
| curl -fsS "$URL" --data-binary @- | jq -r .access_token)
C=$(T="$T" jq -n '{token:env.T}' | curl -sS "https://penv.cloud/api/v1/auth/oidc" \
-H 'content-type: application/json' --data-binary @- | jq -r .credential)
PENV_TOKEN="$C" penv pullThe snippet finishes with penv pull, which writes a file. We recommend penv run for a process; penv pull is for a host that needs a file on disk. Connect your CI has the wrapped step.
Related
- Machine identity
- Connect a Platform in the console
- PingOne Advanced Identity Cloud documentation: the value most often set wrong is the client id, which has to be your workspace id