Step-by-step: Configuring jumpcloud as an IdP for AWS SSO (not the other way).

Hey, I was just in your shoes a few weeks ago! That exact step-by-step was surprisingly hard to find. The biggest "aha" for me was getting the entity ID in AWS SSO correct. It's not just the generic JumpCloud URL.

When you're in the JumpCloud app setup, make sure you copy the "IDP Metadata URL" they give you at the end. That's what you paste into AWS SSO's "Metadata document" field. Then, for the attribute mapping in AWS SSO, you'll need to set `Subject` to `${user.email}` and add an attribute for groups. The format is `memberOf;join=","` to pass all the user's group memberships.

Oh, and a pitfall - the SAML certificate in JumpCloud auto-rotates. You need to go back into AWS SSO and refresh the metadata every time it does, or logins will break. Learned that one the hard way 😅

How are you planning to structure your groups? I'm still deciding between using our department names or more generic role-based groups.

You've hit the nail on the head with the auto-rotation pitfall, it's a genuine maintenance headache. I'd add that you should note the rotation date somewhere you'll actually see it, like a shared calendar. Otherwise, you'll get the midnight call.

On your group question, department names are a trap. They change with every reorg. Use functional roles, like `aws-s3-readonly`. Map those to permission sets. It keeps the coupling loose.

One more nuance on `memberOf;join=","`: that string needs to be in the exact case. I've seen it fail because someone typed `memberof`.

Absolutely on the calendar point. I have a quarterly audit reminder set, not just for the cert rotation but to review those functional group memberships. Reorgs creep in, and suddenly someone from finance is in `aws-dev-deploy` because they helped with a budget script once.

The `memberOf` case sensitivity is a classic gotcha. I've also seen AWS SSO silently drop the attribute if the claim name in the assertion uses a different namespace than ` http://schemas.xmlsoap.org/claims/`. JumpCloud's default isn't always what AWS expects. You sometimes have to manually define the attribute in the JumpCloud app config to match AWS's expected namespace exactly.

The version suffix is a solid operational pattern. We've adopted it for permission set updates, but it's equally valid for group naming. The one complication we've run into is that AWS SSO's provisioning from SCIM doesn't always handle renaming well. If you decommission `aws-id-finance-ro-v1` and replace it with `v2`, you have to verify the old group assignment is truly removed from all users in the IdP before deprecation, otherwise you risk orphaned SSO assignments.

On the cookie clearance, that's a precise troubleshooting step. I'd also recommend checking for any browser extensions that might interfere with SAML, like certain password managers that auto-fill or intercept POST requests to the SAML ACS endpoint.

Spot on with the click-by-click, that's exactly what's missing from most guides. The metadata file point is critical, I've had that entityID mismatch cause a full day of confusion.

One tiny addition on the groups - if you add that custom attribute *after* users have already logged in via the app, you might need to go into AWS SSO and manually run a user sync from the IdP. Their existing assignments won't pick up the new `memberOf` attribute automatically until they sign in again or you force a sync.

Also, for the clock skew, I've seen it where JumpCloud's system time is fine but an intermediate proxy adds its own timestamp headers, confusing the assertion validation. Setting the window to 3 minutes in AWS is a good blanket fix for that weirdness.

That forced sync after adding the attribute is a good call. It's an easy step to forget when you're just testing the config. I've even seen the AWS SSO UI lag, where you run the sync and it says "Success" but the assignments still don't populate for a few minutes, which makes you doubt everything else you just set up.

The clock skew blanket fix is pragmatic. Sometimes the fix for a one-off, weird proxy issue is just to give the systems a bit more breathing room.

The namespace issue you mentioned is a subtle but critical one. JumpCloud's admin console sometimes presents ` http://schemas.jumpcloud.com/ns/sso/claims/memberOf` as a default, which AWS SSO won't recognize without explicit mapping.

You can define a custom attribute in the JumpCloud app's SSO configuration. Use `memberOf` as the name and set the value to `{!groups_dn}`. Crucially, you must also set the "Namespace" field to ` http://schemas.xmlsoap.org/claims/` for it to match AWS's expectation. Without that namespace, the assertion passes but the attribute is ignored.

Don't use the SAML IdP setup in AWS SSO if you have over 50 users. Use SCIM provisioning instead.

The SAML handshake steps are covered above. But you'll still be manually assigning users to permission sets in AWS. That's a compliance nightmare.

JumpCloud's AWS SSO connector uses SCIM. It syncs users *and* groups automatically. Map a JumpCloud group to an AWS SSO group, then assign a permission set to that group once. It's one-to-one mapping.

Pitfall: AWS SSO SCIM requires a bearer token from JumpCloud. That token is a long-lived credential. Store it in secrets manager, not in your config notes.

Groups in JumpCloud should match permission set names. `aws-prod-readonly` maps to a permission set of the same name. Don't get clever.

You'll thank yourself when onboarding user 51.

Absolutely agree on SCIM being the way to go for any real scale. That manual assignment just doesn't scale.

One thing to watch: if you're synchronizing groups from JumpCloud to AWS SSO groups, be mindful of the group name character limits. AWS SSO has a 100-character limit for group names, while JumpCloud is more forgiving. I've seen a sync fail silently because a long, descriptive group name got truncated.

Also, the SCIM sync interval from JumpCloud isn't instantaneous. It can take a few minutes for a group membership change in JC to reflect in AWS, so set expectations for users when you're doing access reviews.

Listen to user64. Use SCIM. The SAML-only setup in the replies is a trap for anything beyond a tiny team.

For your steps:

1. In JumpCloud, add the "Amazon Web Services (AWS)" application from the Catalog. It's a pre-configured connector.
2. In AWS SSO, go to "Settings", choose "Provisioning", and enable automatic provisioning. It'll give you an SCIM endpoint and a token.
3. In the JumpCloud AWS app settings, paste that SCIM endpoint and token into the "Provisioning" tab. Turn on "Create Users", "Update Users", and "Create Groups".
4. Create a test group in JumpCloud, like `aws-readonly`. Add a user to it. It'll sync to AWS SSO as a group. Then you assign a permission set to that AWS SSO group once.

The common pitfall is messing with SAML attributes at all. If you use the SCIM connector, it handles the group mapping for you. You assign permission sets to the *synced groups* in AWS, not via `memberOf` claims.

Double-check the token storage and the group name length mentioned in the thread. That's where it usually breaks.

Welcome, and great question! The SAML-only path is tempting to get started, but you've already gotten the best advice here: **use the JumpCloud AWS SSO SCIM connector**. It handles the SAML trust for you automatically and solves the real problem: provisioning.

To build on the excellent steps from user344, here's the one thing I'd double-check that always trips me up: the **AWS SSO Provisioning Token**. When you get it from the AWS SSO console, it includes a long, auto-generated secret access token. Copy the *entire* string, including the part after the `:`. JumpCloud's provisioning tab expects the full token as a single value in the "Token" field, not just the secret part.

Also, on group naming, I like to prefix everything with `aws-sso-` in JumpCloud (e.g., `aws-sso-prod-readonly`). It keeps them visually distinct from other app groups and makes filtering easier. Once they sync over, you'll see them in AWS SSO under "Groups from your identity source" and can assign permission sets directly. No manual user-by-user assignment!

Alright, but I have to push back on the request for a *"beginner-friendly, step-by-step walkthrough."* That's exactly how you end up with a fragile, half-implemented SAML setup that auditors like me tear apart later.

Everyone here saying to use the SCIM connector is correct. If you ignore that and go manual SAML just to follow a guide, you're building a manual user-provisioning process from day one. How are you planning to handle access reviews, or terminations? A spreadsheet?

> making sure the handshake is correct

The handshake is the easy part. The real pitfall is assuming the setup ends there. The JumpCloud AWS SSO connector app configures the SAML trust for you. Your checklist shouldn't be about SAML attributes, it should be:
* Where is your SCIM bearer token stored (please don't say a Confluence page)?
* Have you tested removing a user from a JumpCloud group and verified their AWS access is gone within the sync window?
* What's your incident response plan for when this sync breaks?

You've gotten fantastic advice here, especially the strong push toward SCIM provisioning. Since you asked for a step-by-step, I'll give you one for the *correct* path using the JumpCloud AWS SSO connector, which configures the SAML trust for you behind the scenes.

1. In your JumpCloud admin console, go to the Applications catalog and add "Amazon Web Services (AWS)".
2. In AWS SSO, go to Settings -> Provisioning. Enable automatic provisioning and copy the **entire** SCIM endpoint and token (the full `:bearerTokenString`).
3. Back in JumpCloud's app config, paste those into the Provisioning tab. Enable "Create Users", "Update Users", and "Create Groups".
4. Create a test group in JumpCloud (like `aws-sso-prod-read`), add a user, and wait a few minutes for the sync.
5. In AWS SSO, assign a permission set to the newly synced group. Done.

The common pitfall is in step 2 - that token includes a colon, and you need to copy the whole thing as one value. Also, what's your plan for naming groups to keep them distinct from other directory groups?

Your point about group naming is critical, but I think prefixing strategies like `aws-sso-` can create a different kind of management overhead. You end up with semantic duplication across systems.

A cleaner approach is to enforce a consistent naming convention at the identity source, then use JumpCloud's "Group Name Transform" feature in the AWS app configuration to add a prefix or suffix *only* for the SCIM sync. This keeps your JumpCloud directory clean while meeting AWS SSO's naming requirements or your own tagging policies. The transform rule is applied during the provisioning call, so the group `prod-read` in JumpCloud can become `aws-prod-read` in AWS without altering your source directory.

This also sidesteps the 100-character limit issue mentioned earlier, as you can configure the transform to truncate.

Hey there! Welcome to the forum! You've already gotten the golden advice from folks above: skip the manual SAML config and go straight for the JumpCloud AWS SSO connector in their catalog. It does the SAML handshake for you and handles the user/group sync.

One small thing I'd add to what's been said: when you first set up that connector app in JumpCloud, go to the **Sign On** tab first and save it. That triggers the creation of the SAML trust on the AWS side automatically. *Then* go to the Provisioning tab to paste your SCIM endpoint and token. If you do provisioning first, sometimes the SAML side isn't ready and you'll get confused. Good luck