Restricting Specific Users from Logging into EC2 via Console After SAML Federated Login

In an AD + SAML federated identity scenario, users may log into the AWS console through the same high-privilege IAM Role. If you only want to restrict a subset of those users from using Session Manager or EC2 Instance Connect to log into instances, you can use the aws:userid condition key to create an explicit Deny.

Scenario

In a customer environment, many domain users log into the AWS console via SAML AssumeRole, potentially using high-privilege roles like PowerUser or Administrator.

Due to compliance requirements, certain users need to be restricted from accessing EC2 instances through the console, primarily involving two capabilities:

• SSM Session Manager: ssm:StartSession
• EC2 Instance Connect: ec2-instance-connect:SendSSHPublicKey

Why Not Use RoleSessionName

After SAML federated login, IAM generates a session identifier. The more stable and available global condition key for policy evaluation is aws:userid. It typically contains the role ID and session name, in a format like:

<role-id>:<session-name>

Because the role ID portion changes with the Role, it is not suitable for hardcoding. Instead, you can use a wildcard to match the session suffix:

*:user-or-ou-id

Example Policy

Add an explicit Deny to the target IAM Role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2LoginForSpecificFederatedUsers",
      "Effect": "Deny",
      "Action": [
        "ssm:StartSession",
        "ec2-instance-connect:SendSSHPublicKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:userid": [
            "*:<user-or-ou-id>"
          ]
        }
      }
    }
  ]
}

Explicit Deny takes priority over Allow, so even if the Role already has high-privilege policies, users matching the condition will still be blocked.

Verification Method

1. Log into the console as the target SAML user.
2. Attempt to connect to EC2 via Session Manager.
3. Attempt to use EC2 Instance Connect.
4. Then verify that unrestricted users are not affected.

If the Deny is working, the target user will be denied when calling the related APIs.

Recommended Long-Term Approach

Hardcoding user suffixes based on aws:userid can quickly solve the problem, but the maintenance cost is high. A better approach is to split permissions at the identity source level:

• Create a restricted user group in AD, e.g., AWS-No-EC2-Login.
• Map different user groups to different IAM Roles in the IdP.
• Create a dedicated restricted Role that does not grant EC2 login capabilities.

This makes permission boundaries clearer and easier to audit and automate.

Summary

If you need to temporarily restrict certain SAML users from logging into EC2 via the console, you can use aws:userid + explicit Deny to precisely block ssm:StartSession and ec2-instance-connect:SendSSHPublicKey.

In the long term, it is recommended to manage user grouping and Role mapping at the identity source side, rather than maintaining increasingly complex conditional policies within a single high-privilege Role.