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 set 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:

• Private Workspace: If the user is the only member of a private workspace and is deactivated, the workspace's visibility will be changed to that of the team, and the team will be the new workspace admin. If there are any other users associated with the private workspace with the viewer role, then the user deactivation will promote the other user to the editor role, keeping the visibility of the team private.
• Public Workspace: If the user is the only member of a public workspace and the user is deactivated, the workspace's visibility will remain public, and the team will be the new workspace admin. If other users are associated with the public workspace with the viewer/roles role, they won't be promoted to elevated access roles.
• Team Workspace: If the user is the only member of a team 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 team workspace have the viewer/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 visibility will continue to be partner, and the team will be the new workspace admin. If other users associated with the Partner Workspace have viewer/editor roles, they won't be promoted.

Upon reactivation, the user regains access to their personal 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 accessible to other team members, they'll no longer have read access to them. For other workspaces such as Public and team 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 the personal workspaces to any existing team admins. Removal of a user account should be 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, if the user is added to the team again, the read access to the team workspaces or any access to the personal workspaces isn’t restored.

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.