AWS STS

Connect

This Free service needs no license key. Start Vera as in Get started, then run this in a terminal of its own, from an empty scratch directory. It gives the official AWS CLI dummy credentials and a config file of its own, so no AWS account is needed and your own AWS profile isn't touched.

export VERA_ENDPOINT="http://localhost:5003"
export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test
export AWS_REGION=us-east-1 AWS_DEFAULT_REGION=us-east-1
export AWS_SHARED_CREDENTIALS_FILE=/dev/null
export AWS_EC2_METADATA_DISABLED=true
export AWS_PAGER="" AWS_CLI_AUTO_PROMPT=off
unset AWS_PROFILE AWS_DEFAULT_PROFILE
unset AWS_SESSION_TOKEN AWS_SECURITY_TOKEN
unset AWS_WEB_IDENTITY_TOKEN_FILE AWS_ROLE_ARN AWS_ROLE_SESSION_NAME
unset AWS_CONTAINER_CREDENTIALS_FULL_URI
unset AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
cat > vera-aws-config <<'EOF'
[default]
region = us-east-1
output = json
cli_binary_format = base64
s3 =
    addressing_style = path
EOF
export AWS_CONFIG_FILE="$PWD/vera-aws-config"

When you've finished every example in this terminal, close it and delete vera-aws-config, not before.

The emulator serves STS’s 2011-06-15 API over the AWS Query protocol, through the AWS CLI’s sts commands. With the setup’s dummy credentials, the caller is the user emulator in the account configured on your Vera instance: arn:aws:iam::123456789012:user/emulator in the examples.

Example

Check who you are, then ask for session credentials. Neither request needs a file or an IAM role.

aws --endpoint-url "$VERA_ENDPOINT" sts get-caller-identity

With the setup’s dummy credentials, the response is:

Output

{
    "UserId": "AIDACKCEVSQ6C2EXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/emulator"
}

Request session credentials for 900 seconds. The query prints only their expiry, so the session’s secret key and token aren’t shown:

aws --endpoint-url "$VERA_ENDPOINT" sts get-session-token \
  --duration-seconds 900 \
  --query 'Credentials.{Expiration:Expiration}' --output json

It prints an Expiration about 15 minutes after the request, such as {"Expiration":"2026-11-05T21:03:23+00:00"}. The time differs on every run. That’s the returned field only: whether the emulator rejects the credentials once they expire wasn’t tested.

Neither command creates a resource, and the session credentials aren’t put into your shell, so there’s nothing to clean up.

Supported features

• Caller identity: GetCallerIdentity returns the default caller for the dummy credentials.
• Session tokens: GetSessionToken issues session credentials with an Expiration about the requested duration ahead.
• Role sessions: in Vera 1.2.2, AssumeRole and GetCallerIdentity worked with a freshly created IAM role. In an earlier check on Vera 1.2.0 preview, AssumeRole returned session credentials, and GetCallerIdentity signed with them returned the assumed role’s ARN and the session’s name.
• Also served, not yet tested: assuming roles with SAML or a web identity, AssumeRoot, federation tokens, access key information, decoding authorization messages and web identity tokens.

Limitations

The main limits are below. A few more apply to every service, and the API coverage notes cover smaller differences.

• Emulator credentials only. The identities and session credentials belong to the emulator, not AWS. A successful response doesn’t establish real AWS authentication or authorization.
• GetCallerIdentity didn’t check signatures in earlier testing, on 3 November 2026: it succeeded for an unsigned request and for one with an invalid signature, so a successful call doesn’t show that its credentials are valid. That was one observation, not a full test of request authentication.
• Expiry wasn’t tested. GetSessionToken returns an expiry time, but whether expired credentials are rejected wasn’t checked, and neither were duration limits.
• Role session options weren’t tested. In Vera 1.2.2, assuming a freshly created role worked, but trust policies, external IDs, role chaining and session policies weren’t tested.

API coverage

Every operation in AWS's published 2011-06-15 API (SDK model, botocore 1.43.105), and whether the emulator implements it. Availability combines the earlier implementation inventory with the dated observations below; checking a page's example does not verify every operation. Each note names its evidence first; an observation given without a build or date comes from earlier testing, on 3 November 2026. What the statuses mean

Operation	Status	Notes
AssumeRole	Implemented	Local observation: Vera 1.2.2, 8 November 2026 — worked with a freshly created IAM role. Local observation: Vera 1.2.0 preview, 5 November 2026 — returned session credentials for a role, and GetCallerIdentity signed with them returned the assumed role's ARN and session name. The role was left behind by an IAM create request that answered an error, so that run wasn't a reliable setup. Trust policies, external IDs, role chaining, session policies and expiry weren't tested.
AssumeRoleWithSAML	Implemented
AssumeRoleWithWebIdentity	Implemented
AssumeRoot	Implemented
DecodeAuthorizationMessage	Implemented
GetAccessKeyInfo	Implemented
GetCallerIdentity	Implemented	Local observation: Vera 1.2.2, 8 November 2026 — worked with a freshly created IAM role. Local observation: Vera 1.2.0 preview, 5 November 2026 — returned user/emulator in account 123456789012 for the dummy credentials, and the assumed role's ARN and session name when signed with AssumeRole credentials. Earlier check, 3 November 2026: Succeeded for an unsigned request, one with an invalid signature and one naming API version 1900-01-01.
GetDelegatedAccessToken	Implemented
GetFederationToken	Implemented
GetSessionToken	Implemented	Local observation: Vera 1.2.0 preview, 5 November 2026 — with --duration-seconds 900, issued session credentials whose Expiration was about 15 minutes after the request. That shows issuance only: whether expired credentials are rejected wasn't tested.
GetWebIdentityToken	Implemented