SSO and SCIM FAQs

Following are frequently asked questions about configuring and using single sign-on (SSO) and System for Cross-domain Identity Management (SCIM) in Postman.

Does enabling SSO for one team impact other teams that aren't on SSO?

SSO configuration is specific to each Postman team. An organization can have multiple Postman teams, each with different (or the same) auth methods configured and enabled. However, this isn't the case for domain capture. Domain capture consolidates all of the Postman user accounts within your organization into one team.

When provisioning a user, which data is mapped from the IdP to Postman?

In provisioning, email is the primary attribute used for user mapping. The user's first name, last name, and active status fields must be included in the provisioning request. The first name and last name fields can be left blank if necessary. Therefore, the email, first name and last name, and active status (activation or deactivation) are the key attributes employed for setting up a new account in Postman.

How does enabling SSO and SCIM impact existing users?

If users were part of a team before enabling SSO and SCIM, and they're not supposed to have access by SSO and SCIM, they will still be on the team and need to be manually removed if they're no longer needed.

Users who were active before the SCIM implementation, including those who are meant to have access by SSO and SCIM, will be managed by SCIM as long as their email address is correctly mapped to an identity provider (IdP). Their email address needs to be the same in both Postman and the IdP.

What is SSO JIT provisioning?

SSO Just-in-Time (JIT) provisioning allows a user to provision themselves to the Postman team by signing in to the team using the SSO IdP. Thus, JIT provisioning automatically adds users to the team without an invite or approval, if enabled. They can sign in by the IdP only if they're in the Active Directory (AD) group that grants them access.

If JIT isn't enabled, users will receive an error message and will need an invitation to join the team. It's recommended to have JIT provisioning enabled for smooth user onboarding. For a team with domain capture turned on, JIT behaves similarly.

Can I test my SSO setup without disrupting user workflows?

To conduct testing without disrupting user workflows, a team can set up an authentication method for testing. This practice is commonly used, especially during IdP migrations.

There are two recommended approaches for testing:

• Maintain the email and password authentication method alongside proper SSO and user sign in. After verification, turn off any other authentication methods.
• Temporarily label the authentication method as Test and notify users about the testing strategy, available authentication methods, transition dates, and more.

If an IdP (such as Okta) goes down, is there a way to bypass SSO so users can continue their access?

Yes, admins can toggle the authentication methods they want to turn on or off.

If a user and account were created with JIT provisioning from their IdP (while Postman Auth was inactive), that user would need to go through the Forgot Password flow to update (populate) their Postman password.

What's the difference between temporarily deactivating a user with SCIM and removal from the team?

Temporary deactivation

Deprovisioning, or temporary deactivation, removes a user from your Postman team and blocks the account from authenticating into Postman. The major use case of SCIM deprovisioning is to provide a mechanism for the customer to manage the seats effectively between team members. You can deprovision a user account with the IdP integrated with SCIM. The SCIM deprovisioning will be triggered by removing the Postman SCIM application from the IdP for a user. While the deprovisioned user won't be able to reuse the same enterprise context to sign in, they will have another context provided where they can sign in with a Postman username and password.

Deactivation results in the following impact on workspace visibility:

• Internal Workspace: If the user is the only member of an internal workspace and is deactivated, the workspace visibility will stay with the team, and the team will be the new workspace admin. If other users associated with the internal workspace have the Viewer or Editor roles, they won't be promoted.
• Public Workspace: If the user is the only member of a public workspace and the user is deactivated, the workspace type will remain public, and the team will be the new workspace admin. If other users associated with the public workspace have Viewer or Editor roles, they won't be promoted.
• Partner Workspace: If the user is the only member of a Partner Workspace and is deactivated, the workspace type will continue to be partner, and the team will be the new workspace admin. If other users associated with the Partner Workspace have Viewer or Editor roles, they won't be promoted.

Upon reactivation, the user regains access to their workspaces within the team, but access to any shared resources (Private/Team/Public/Partner Workspace) isn't restored. For example, for Private and Partner Workspaces, if they were previously an Admin or editor, after reactivation, they won't regain the same access. Since Private and Partner Workspaces aren't available to other team members, they'll no longer have read access to them. For other workspaces such as Public and internal workspaces, they'll have the same access to the resources as other team members.

Removal from team

The user removal flow will remove the user from the team by removing access to all team-level workspaces. The user must assign their workspaces to any existing team admins. Removal of a user account is done through Postman. The deleted user can't sign in to the same team. However, they have a different context for signing in with a Postman username and password.

Unlike the SCIM flow, re-adding a user to the team doesn’t restore their read access to internal workspaces or any other access to their workspaces.

How do IdP groups and licenses work with SCIM provisioning?

SCIM provisioning works until all seats are filled. If Auto-Flex or True-up is enabled, more users can be added beyond the initial license count. In the case of group provisioning, the users associated with the group need to be provisioned prior. Otherwise, group provisioning will fail.

Instead, teams are recommended to verify the email domains, which will automatically provision users of the same domain name to the team without any user interaction.