Check that Prism can assume its role in an account
POST/accounts/validate
Checks whether Prism can assume its switch role in an AWS account, and changes nothing.
This is the pre-flight for onboarding. It performs one sts:AssumeRole
into the account, presenting your tenant UUID as the external ID, and
reports whether that succeeded. Nothing is created, nothing is written,
and the account does not have to be registered with Prism.
What a success proves is narrow. It proves the role exists, trusts
Prism, and accepts your external ID. It says nothing about whether the
role's policy allows creating a SAML identity provider, the permission
onboarding actually needs. An account can pass this check and still fail
POST /accounts/onboard with a 502.
A failed check is a 400, not a 502. That is the opposite of the onboarding operations, which blame AWS with a 502 for the same class of failure. Do not read the 400 as "your request was malformed": the request was fine and the trust relationship was not.
Request
Responses
- 200
- 400
- 401
- 403
- 404
- 500
The role was assumed. See above for how little that proves.
Either the request was malformed, or the role could not be
assumed. The same status covers both, so read message to tell
them apart.
The malformed causes are a body that is not valid JSON and an absent
or empty accountId. The account number's format is not checked, so a
number that is not twelve digits reaches AWS and comes back as the
other kind of 400.
The assume-role failure means one of: no such role in that account,
its trust policy does not name Prism, or the external ID it expects is
not your tenant UUID. error carries the AWS message.
Authentication failed: the X-API-Token header was missing, malformed,
expired or not recognised.
This response is text/plain, not JSON. It is written by
http.Error in the authentication middleware, which runs before any
handler and therefore before anything that would build a JSON envelope.
A client that unconditionally JSON-parses response bodies will fail on
this one, so check the status code first.
The token is valid, but it is not allowed to act on this tenant.
An API token is minted inside one tenant and stays bound to it for life.
Sending it to a path whose tenant segment names a different tenant is
refused here, in middleware, before the operation runs, so this says
nothing about the resource you asked for, only about which tenant the
path named. Check the tenant server variable against the console the
token was created in.
No tenant matches the tenant segment of the request path. An account Prism cannot reach is a 400, not a 404.
Prism's AWS integration is not configured on this deployment, so no check could be attempted.