JumpCloud SSO Integration with AWS IAM Using SAML 2.0

Objective

This blog shows how users can sign in to AWS through JumpCloud, without creating a separate IAM user for every employee.

You will also learn how one JumpCloud application can give access to many AWS IAM roles. After login, the user simply picks the role they need.

Traditionally, people use IAM users with a password and access keys. This is hard to manage when a company has many employees. With SSO, JumpCloud keeps the users, and AWS gives short-lived access only when needed.

Why Direct IAM Federation?

This blog uses direct SAML 2.0 federation between JumpCloud and AWS IAM. It works well when you need SAML sign-in to a specific AWS account, or when you want full control of the IAM roles and trust policies.

If you need one central place to manage workforce access across many AWS accounts, AWS recommends AWS IAM Identity Center. Please compare both options before you choose your design.

How the Sign-In Works

Behind a simple click, there are a few clear steps. The key point is that the browser carries the SAML response from JumpCloud to AWS.

Who does what

Final flow

Prerequisites

Keep these ready before you start.

In this blog, the sample AWS account ID is 123456789012. Replace it with your own account ID.

Step 1 — Create a JumpCloud Account

Go to the official JumpCloud website and create your organization. You need administrator access, because SSO application settings need admin rights. JumpCloud also lists an admin account and the SSO entitlement as requirements for the AWS IAM connector.

Step 2 — Create a Test User

In the JumpCloud Admin Console, open this path:

Use demo details like these:

Save the user. Later, this user will be allowed to open the AWS application.

Step 3 — Create a User Group

Groups make access easy to manage. Create one group for the people who can use AWS.

Step 4 — Add the AWS Application in JumpCloud

This is the main JumpCloud setting. Open this path and search for the AWS connector:

Fill in the general information:

When Show in User Portal is on, authorized users can see the AWS tile in their JumpCloud portal.

Step 5 — Export the JumpCloud Metadata

Open the application and go to the SSO tab. JumpCloud creates its own SAML details, such as the IdP certificate and the IdP URL. The SSO URL looks like this (your region may be different):

https://sso.jumpcloud.com/saml2/amazonwebservicesiam

Click Export Metadata and save the XML file, for example JumpCloud-AWS-IAM-metadata.xml. AWS uses this file to trust JumpCloud as the SAML identity provider.

Important: The SSO tab may show an IdP private key. Never copy, share, or publish it. AWS does not need it. AWS only needs the metadata file, which contains the public certificate.

Step 6 — Create the SAML Provider in AWS

Now open the AWS console and go to IAM:

After you save, the provider ARN looks like this:

The SAML provider only sets up trust with JumpCloud. Users still need IAM roles to get any permissions.

Step 7 — Create the IAM Roles

This is where one JumpCloud app becomes powerful. Create three roles, each with a different job. The role names below are the ones used in the screenshots.

Create each role

1. For Trusted entity type, choose SAML 2.0 federation.
2. For SAML provider, choose jumpcloud.
3. Choose Allow programmatic and AWS Management Console access.
4. Check that the condition is SAML:aud with the value https://signin.aws.amazon.com/saml.
5. Attach the permission policy from the table above.
6. Enter the role name and click Create role.
7. Repeat for the other two roles.

Trust policy
The console builds the trust policy for you. The important part looks like this:

In simple words: this policy lets users who signed in through the JumpCloud SAML provider assume this role using sts:AssumeRoleWithSAML. The SAML:aud condition makes sure the assertion is meant for the AWS sign-in page.

Step 8 — Send the Roles from JumpCloud

Go back to JumpCloud and open the AWS application. On the SSO tab, find the attribute settings. JumpCloud must send the role details inside the SAML assertion. These are the attributes we use:

Role attribute format

Add one Role attribute for each role. Each value has two ARNs, separated by a comma and no space: first the role ARN, then the SAML provider ARN.

Check each ARN carefully. A small typo in a role name, account ID, or provider name will stop the role from working.

Session duration

SessionDuration is the time (in seconds) you request for the console session, for example 3600 for one hour. It must fit inside the maximum session duration set on the IAM role. Keep it short for powerful roles.

What the SAML assertion carries

This simple view shows what JumpCloud sends to AWS after the user signs in:

Step 9 — Authorize the Users in JumpCloud

Creating the application does not give access to everyone. JumpCloud blocks users from an SSO application until an admin allows them.

1. Open the AWS application in JumpCloud.
2. Go to the User Groups tab.
3. Select the group AWS-SSO-Users.
4. Click Save.

Validation

Now test the full login with the demo user.

1. Open the JumpCloud User Login page and sign in with the demo user.
2. In the User Portal, click the Amazon Web Services IAM tile.
3. Check that AWS shows the Select a role page with all three roles.
4. Select jumpserverpoweruserrole and click Sign in.
5. Confirm that the AWS console opens.
6. Open a service that the policy allows and confirm it works.
7. Open the IAM dashboard. Some IAM details show Access denied. This is expected, because PowerUserAccess does not allow IAM management.

Expected result

You can also open AWS CloudTrail and look for the AssumeRoleWithSAML event. It confirms that the federated login worked.

Security and Production Considerations

A working lab is only the start. Think about these points before you use this design in production.

• Turn on MFA in JumpCloud, especially for users with powerful roles.
• Use least privilege. Give each IAM role only what the job needs.
• Do not use the AWS root user for setup or daily work.
• Use short session durations for privileged roles.
• Never share the IdP private key.
• Watch the SAML certificate expiry. Plan the renewal before it expires.
• Monitor access with AWS CloudTrail.
• Review group assignments in JumpCloud on a regular basis.
• Keep a break-glass path. Make sure you can still enter AWS if SSO fails.

Conclusion

You now have JumpCloud working as the identity provider for AWS IAM. Users sign in once, pick the role they need, and get temporary access that expires on its own. There are no extra IAM users to manage.
Direct IAM federation is a good choice for specific accounts and clear role needs. For large multi-account setups, also look at AWS IAM Identity Center.