Connect AWS IAM Identity Center

Who this is for: admins who connect Liitora to AWS IAM Identity Center, for example to check which AWS groups a leaver is still in, or to cut off someone’s AWS access in an emergency.

Before you start: you need the Manage connections and Manage secrets permissions in Liitora (Admin and Editor). In AWS you need access to the IAM Identity Center console of your organization, and your users must come from an external identity provider with automatic provisioning (SCIM) turned on.

Liitora reaches IAM Identity Center through its SCIM API, the same interface your identity provider uses to send users and groups to AWS. It signs in with a SCIM access token that you generate in the IAM Identity Center console.

The AWS IAM Identity Center (SCIM) connection template fills in everything that is the same for every company. You enter only your SCIM endpoint and the secret that holds the token.

What the token can do

Read this before you generate a token:

The token can do everything, not only read. AWS has one kind of SCIM token, and it can’t be limited. The token you give Liitora can create, change and delete every user and group in your IAM Identity Center instance, even if your workflows only read. Liitora offers no action that deletes anything, and it keeps the token in its secret store, where no person and no workflow can read it back. Still, treat it like an admin password.
It takes your second token slot. An instance holds at most two access tokens, and your identity provider already uses one. Liitora’s token takes the second, which you would otherwise use to rotate your identity provider’s token without a break. Before you rotate that token, plan which token to delete first, or delete Liitora’s token for the time it takes and add a new one afterwards.
It lasts one year. AWS reminds you in the console and in the AWS Health Dashboard from 90 days before it expires. Liitora can’t read the expiry date from AWS, so set an expiry date on the secret too.
AWS logs every call. Each request Liitora makes, reads included, appears in your AWS CloudTrail with the event source identitystore-scim.amazonaws.com, with names hidden. So you can see exactly what Liitora read or changed. Tokens made before September 2024 don’t show up in CloudTrail, which is one more reason to give Liitora a new one.
Your identity provider stays in charge. AWS treats your identity provider as the owner of users and groups. Use Liitora’s changes only as an emergency step, and make the same change in your identity provider, or its next sync may undo it.

Every workflow that uses the connection shows it on the approval page, so the person who approves a workflow sees that it holds this token, even when it only reads.

What the template sets for you

These settings come from the template and can’t be changed, so the token only ever goes to AWS:

Setting	Value
Address	Your SCIM endpoint: `https://scim.<region>.amazonaws.com/<tenant ID>/scim/v2`, or the dual-stack form `https://scim.<region>.api.aws/<tenant ID>/scim/v2`
Sign-in	The SCIM access token, sent as a bearer token
Other hosts it may call	none
Test connection	Reads the server’s settings (`/ServiceProviderConfig`), which changes nothing

The endpoint must be exactly in one of those two forms. Anything else is refused, including another host, a port, a user name, a query or extra path parts, so a typo can’t send the token anywhere else. SCIM works only in your instance’s primary AWS Region, so use the endpoint IAM Identity Center showed you.

Find your SCIM endpoint

AWS shows the SCIM endpoint only once, when automatic provisioning is turned on. If nobody kept it:

Open the provisioning settings of the AWS IAM Identity Center app in your identity provider. The SCIM endpoint was pasted there when provisioning was set up.
Copy it as it is. It starts with https://scim. and ends in /scim/v2.

If automatic provisioning isn’t turned on yet, turn it on in IAM Identity Center under Settings > Identity source > Automatic provisioning, and set up your identity provider with the endpoint and token AWS shows. That first token belongs to your identity provider.

Generate the token for Liitora

Sign in to the AWS Management Console and open IAM Identity Center.
Go to Settings and open the Identity source tab.
Select Actions > Manage provisioning.
Under Access tokens, check how many tokens there are. If there are already two, delete an expired or unused one first, or wait until you rotate your identity provider’s token.
Select Generate token and copy it. AWS shows it only once.

Add the connection in Liitora

Open Secrets and add a secret of the kind API key, for example aws_scim_token. Paste the token as its value and set Expires on to one year from today. See Add a secret.
Open Connections and select Add a connection.
Under Start from, pick AWS IAM Identity Center (SCIM).
Type the Name, for example aws-sso. Workflows use this name.
Pick the Environment.
Paste the SCIM endpoint.
Under Secrets, type aws_scim_token for SCIM access token, or select Ask for it so someone adds the value.
Select Save, then Test connection. It says It works when AWS accepts the token.

Your AI assistant can do steps 2 to 8 with the create_connection_from_template tool. It asks you for the SCIM endpoint and never sees the token. See the MCP tools reference.

If the test fails with HTTP 401, the token is wrong, expired or deleted, or the tenant ID in the endpoint is wrong: AWS answers the same way for both. With HTTP 403, check that automatic provisioning is still turned on.

When AWS slows you down

IAM Identity Center allows about 40 reads and 25 changes a second for each instance, and your identity provider’s sync uses the same budget. When a workflow goes over the limit, AWS answers 429. Liitora waits and tries again a few times, and then the step fails and says so. Add retry: to the step, or run the workflow at a quieter time.

Check these in your own instance

We built the connection from AWS’s documentation, without a live IAM Identity Center instance. AWS doesn’t document these points, so check them in your instance before you rely on them. Liitora takes the safer path for each, as described in AWS IAM Identity Center actions:

Whether user names are matched without regard to case.
Whether deactivating a user over SCIM ends their sessions the same way as Disable user access in the console, and whether your identity provider turns the user back on at its next sync.
How many results AWS sends in one page.
Whether AWS sends a Retry-After time when it slows you down.

Sources

Written from AWS’s own documentation: