AWS IAM Identity Center actions
Who this is for: people and AI assistants who write workflow steps that check or cut off a person’s AWS access through AWS IAM Identity Center, for example in a leaver check.
Before you start: you need an AWS IAM Identity Center connection. See Connect AWS IAM Identity Center.
These actions are part of our curated platform library. Use them in any workflow as uses: library/aws-identity-center.<name>@v1. Each action uses one connection slot, scim, which takes a connection made from the AWS IAM Identity Center (SCIM) template. You find the same actions in the app under Library, and your AI assistant reads their full contracts with the MCP tool get_action.
| Action | What it does |
|---|---|
library/aws-identity-center.find-user@v1 |
Finds one user by user name (only reads) |
library/aws-identity-center.list-user-groups@v1 |
Lists the groups a user is in (only reads) |
library/aws-identity-center.list-group-members@v1 |
Lists the users in a group (only reads) |
library/aws-identity-center.deactivate-user@v1 |
Turns one user off, as an emergency step |
library/aws-identity-center.remove-group-member@v1 |
Removes one user from one group, as an emergency step |
What every action needs. The connection’s SCIM access token. AWS can’t limit that token to reading: the same token can create, change and delete every user and group, so a workflow that only reads still holds it. There is no action that deletes a user or a group.
What these actions can’t show. Which AWS accounts and permission sets a person can use. AWS keeps those outside the SCIM API. The actions show only users and the groups they are in.
What every action does the same way
Section titled “What every action does the same way”- IDs, not names, for groups and changes. Each user and group has an ID in IAM Identity Center, like
94f1e0b3-c394-48d5-8ab1-2c122a167074or9067729b3d-94f1e0b3-c394-48d5-8ab1-2c122a167074. Find a user’s ID withaws-identity-center.find-userand a group’s ID withaws-identity-center.list-user-groups. Anything else in an ID field is refused before a request is sent. - Only the data the check needs. AWS always sends the whole user, with names, emails, phone numbers and job details. The actions keep only the ID, user name, display name and whether the user is active, and drop the rest before it reaches your run.
- Pages, with a limit. AWS sends long lists a page at a time. The actions read the pages for you, up to
max_pagespages andmax_itemsitems. When more was left, the output saystruncated: true. - Values stay values. A user name can’t hold double quotes or backslashes, so it can’t change what the action asks AWS for.
- When AWS slows you down. AWS answers
429when your instance gets too many requests, and your identity provider’s sync shares the same limit. Liitora waits and tries again a few times. If it keeps happening, the step fails and says so. Addretry:to the step, or run the workflow at a quieter time. - Errors. A failed step says what it tried, the HTTP status, AWS’s request ID and what to check. AWS’s own error text is left out, because it can contain details of the request. HTTP 401 means the token is wrong, expired or deleted, or the tenant ID in the connection’s endpoint is wrong. For the actions that only read, a user or group that doesn’t exist is not an error: the output says
found: false. For the actions that change data, it is an error, so a mistyped ID never looks like success. - Not found can mean not assigned. A person who isn’t assigned to AWS in your identity provider doesn’t exist in IAM Identity Center at all.
aws-identity-center.find-user
Section titled “aws-identity-center.find-user”Finds one user by user name. The user name is usually the person’s sign-in address in your identity provider. AWS doesn’t support finding a user by email address.
| Input | Required | What it is |
|---|---|---|
user_name |
yes | The user name, like ada@example.com. Up to 256 characters, without double quotes or backslashes. |
Outputs: found (true or false) and user (id, userName, displayName and active, or null).
AWS doesn’t say whether it matches user names without regard to case. Give the user name the way your identity provider sends it. If AWS returns a user whose user name differs in more than case, or more than one user, the step fails instead of guessing.
- id: aws_user uses: library/aws-identity-center.find-user@v1 connections: { scim: aws-sso } with: user_name: ${{ trigger.body.email }}aws-identity-center.list-user-groups
Section titled “aws-identity-center.list-user-groups”Lists the groups one user is in. IAM Identity Center has no groups inside groups, so every membership is direct.
| Input | Required | What it is |
|---|---|---|
user_id |
yes | The user’s ID (not the user name), for example ${{ steps.aws_user.outputs.user.id }}. |
max_pages |
no | Pages to read at most, 1 to 100. Default 10. |
max_items |
no | Groups to return at most, 1 to 10,000. Default 1,000. |
Outputs: found (false when there is no such user), groups (each with id and displayName), pages and truncated.
aws-identity-center.list-group-members
Section titled “aws-identity-center.list-group-members”Lists the users in one group.
| Input | Required | What it is |
|---|---|---|
group_id |
yes | The group’s ID (not its name). |
max_pages |
no | Pages to read at most, 1 to 100. Default 10. |
max_items |
no | Members to return at most, 1 to 10,000. Default 1,000. |
Outputs: found (false when there is no such group), members (each with id, userName, displayName and active), pages and truncated.
When a group has no members, the action reads the group itself to tell an empty group from a wrong ID, because AWS doesn’t say what it answers for a group that doesn’t exist.
Actions that change data
Section titled “Actions that change data”These two actions each change one thing in IAM Identity Center. Use them as an emergency step, for example to cut off a leaver’s AWS access at once. They share these rules:
- Your identity provider stays in charge. AWS treats your identity provider as the owner of users and groups. Make the same change there too. Otherwise its next sync may turn the user back on or add them back to the group.
- Existing sessions can go on. AWS documents that when a user’s access is turned off in the console, their IAM Identity Center access ends at once and their application sessions within 30 minutes, but sessions in AWS accounts can go on until they expire, for up to 12 hours. Removing a user from a group works the same way for what the group gave them. AWS also warns that a user with an open access portal session can keep starting new sessions until their account access is removed. To end sessions at once, end the user’s active sessions in the IAM Identity Center console.
- One at a time. Each one changes one user or one membership, named by its ID.
- Nothing is deleted. Deactivating can be undone; deleting can’t, and a user who is deleted and created again gets a new ID that breaks their assignments. So Liitora doesn’t offer it.
- Safe to run again. When the change is already done, the step succeeds with
changed: falseand says so instatus. - Dry runs and test runs change nothing. In a dry run, Liitora holds back the change and logs it as “would have sent”. The step succeeds with
dry_run: true,changed: falseandstatus: dry_run. A test run that uses a production connection holds it back the same way. The reads before the change still run for real. - A person approves it first. Like every workflow, a version that uses these actions runs for real only after an admin approves it. See Approve a workflow.
aws-identity-center.deactivate-user
Section titled “aws-identity-center.deactivate-user”Turns one user off (active set to false) without deleting them. It reads the user first. If the user is already inactive, it changes nothing.
| Input | Required | What it is |
|---|---|---|
user_id |
yes | The user’s ID (not the user name). |
Outputs: changed (true when this step deactivated the user), status (deactivated, already_inactive or dry_run), user_id and dry_run.
If AWS answers that the user is still active after the change, the step fails.
- id: cut_off uses: library/aws-identity-center.deactivate-user@v1 connections: { scim: aws-sso } with: user_id: ${{ steps.aws_user.outputs.user.id }}aws-identity-center.remove-group-member
Section titled “aws-identity-center.remove-group-member”Removes one user from one group. It never deletes the user or the group. It reads the user’s groups first: if the user isn’t in the group, it changes nothing and says not_a_member.
| Input | Required | What it is |
|---|---|---|
group_id |
yes | The group’s ID (not its name). |
user_id |
yes | The user’s ID (not the user name). |
Outputs: changed (true when this step removed the user), status (removed, not_a_member or dry_run) and dry_run.
A group that doesn’t exist fails the step. A user who is in more than 10,000 groups can’t be checked, and the step fails and asks you to remove the membership in your identity provider.
What AWS doesn’t document
Section titled “What AWS doesn’t document”We built these actions from AWS’s documentation, without a live IAM Identity Center instance. Where AWS doesn’t say what happens, the actions take the safer path:
| What AWS doesn’t say | What the actions do |
|---|---|
| What a search for an unknown user name answers | An empty answer means found: false |
| Whether user names are matched without regard to case | A match that differs only in case is accepted; anything else fails the step |
| What the member list of an unknown group answers | An empty list is checked against the group itself |
Whether active may be sent as true or false without quotes |
It is sent as "false", as in AWS’s own example |
| What removing a user who isn’t a member answers | Membership is read first, and nothing is sent for a non-member |
| Whether deactivating over SCIM ends sessions like Disable user access in the console | The guide says sessions in AWS accounts can go on for up to 12 hours |
| How many results come in one page | The actions don’t ask for a page size and follow AWS’s next-page cursor until there is none |
| Whether AWS says how long to wait when it slows you down | Liitora uses AWS’s wait time when it gets one, and otherwise waits a little longer each time |
Check these in your own instance before you rely on them, and tell us what you find.
Your data
Section titled “Your data”User records hold personal data such as names, email addresses and phone numbers. The actions keep only the ID, user name, display name and whether the user is active, so the rest never reaches your runs or their logs. AWS records each request in your AWS CloudTrail, with names hidden, so you can see what Liitora read and changed.
Sources
Section titled “Sources”Written from AWS’s own documentation:
- What is the SCIM implementation and Supported API operations
- ListUsers, ListGroups, GetUser and GetGroup
- PatchUser, PatchGroup and DeleteUser
- ServiceProviderConfig
- Users, groups, and provisioning and Provision users and groups from an external identity provider using SCIM
- Understanding authentication sessions, Revoke user access and View and end active sessions for your workforce users
- Quotas and limits
- Logging IAM Identity Center SCIM API calls with AWS CloudTrail
- Troubleshooting IAM Identity Center issues