If you would like to have users sign-in through the systems you already employ, you can do that by setting-up SSO through SAML.

In this article, we will go over the below:

  • Pros & Cons
  • Commonly Asked Questions About PostBeyond Integration
  • What is SAML SSO?
  • How does it work?
  • What are the different types of SAML SSO?
  • Steps to set-up SAML
  • What will SAML SSO login look like?
  • Testing & Troubleshooting Errors



  • User does not have to remember multiple passwords as this leverages their existing work logins
  • Can be connected with Active Directory (AD) so Administrator doesn’t have to worry if user a is terminated


  • Can take longer to set up if the IT team is not prepared ahead of time
  • Users are not grouped accordingly unless the groups match those in the Active Directory or the same list is Preloaded in advance to PostBeyond
  • PostBeyond only accepts one IDP. If you have multiple IDPs, you will need to speak with your engineering team about merging the two

Commonly Asked Questions

  • Do we support multiple IDPs? No, we currently only support one IDP. If you have multiple IDPs within your organization, you will need to work with your IT to make the change before sending the IDP to PostBeyond.
  • Is the format case sensitive in your app, is below explicitly what you need? If by the format you mean username, then no, both CASE@pb.com and case@pb.com would belong to the same user.
  • Are users JIT provisioned? Yes, if user hasn't been created beforehand, it would be created in our system with "user" role and in the root group.
  • Is there any SCIM integration for deprovisioning users? No.
  • Are we able to disable native/cloud login and require SAML authentication? Yes, we can disable email logic and have only SAML SSO login.
  • Is there a sandbox/non-production environment of the application available to SSO? Yes we can set this up.
  • What federation protocols does the application support? SAML 2.0

What is SAML SSO?

SAML SSO is the process of authenticating a user for a service provider via a third party decided upon by the customer.

Users will authenticate themselves via an identity provider service (IDP) chosen by the customer who then confirms to PostBeyond that the person attempting to log into that account is in fact who they say they are.

How does it work?

  1. Users visit their PostBeyond instance login page.
  2. There, they click to be taken to the IDP (Identity Provider). We send information to the IDP notifying them where the user is sent from. This is done in order to ensure that once a user has fulfilled whatever terms they need in order to be authenticated they are sent back to the service provider (PostBeyond).
  3. Users are authenticated by the IDP by any methods they have set up for authentications.
  4. Once their identity is confirmed they are rerouted back to PostBeyond along with the appropriate SAML token confirming their identity validation request from the IDP along with any other necessary information about that user (name, email address, possibly group). If the user is signing in for the first time using SSO, we check to see if the user exists (based on email address sent). If not, we create it in the database and add the user to the instance.

What are the different types of SAML SSO?

  1. Manual Group Management - requires admins to manually group users after they have signed on for the first time.
  2. Groups set-up one time before customer launch - this requires customer to be bulk uploaded a list of users with groups. Subsequent regrouping or grouping of any new users would be done manually.
  3. SAML Auto-sync - groups automatically sync-up according to customer directory - not yet completed by PostBeyond.
  4. Master SSO - SSO for enterprise customers on multiple instances
  5. SLO - Single log-out which forces users to be logged out of other apps authenticated by

Steps to set-up SAML 

In order to set-up, SAML SSO make sure to contact your CSM. From there, you will begin the process to ensure that they activate the set-up.

SAML SSO protocol is about establishing trust between two parties - the Service Provider (which is PostBeyond) and the Identity Provider (the company). Parameters in steps 1 and 2 are used to establish this trust.

NOTE if using OKTA as an IDP: The below are steps to set-up SAML SSO and NOT OKTA as an integration

Step 1: Admin to send PostBeyond Metadata & Attributes

Metadata file(s) to include:

  • Single Sign On Service endpoint
  • Logout Service endpoint
  • EntityId
  • X.509 Cert (certificate can be attached separately - not in the metadata file)
  • Attributes (read below for details)
  • (OPTIONAL) User Groups (read below for details)

Required Attributes

These are the specific attributes we require in order to be able to create and verify accounts. Attribute names can be changed to match however your team sends them over. PostBeyond requires at least the following three attributes:

  1. givenname – user first name
  2. surname – user last name
  3. emailaddress – user email address

We can accept additional attributes upon request (group names). These can be synced based on the customer directory.

User group registration via SSO login

If you choose, you can have it so that new users will log in via SSO and be set-up into groups that already exist in your company's infrastructure.

*Important to note*: This will only work if the groups in the PostBeyond instance perfectly match up with the groups within the company database. Carefully consider this before going down this path to ensure that it is the best option for your team.

To have this completed, please send us a list of user groups.

Step 2: Admin to Retrieve Metadata File from PostBeyond

Step 2 can be complete in tandem with Step 1. The moment the admin notifies the CSM that they want SAML SSO, the feature is turned on and the below information will become available on the instance.

In the instance admin panel, go to 'Settings' > 'Company':

From here, you can download the SAML Metadata from the Service Provider (PostBeyond):

The information in the metadata file that the company's IT team will need to complete the process of verifying the Service Provider (PostBeyond) will include:

  • Login URL
  • EntityId
  • Logout Service endpoint
  • Assertion Consumer Service endpoint

Step 3: PostBeyond to Complete the Process Internally

The PostBeyond team will finalize the process and provide the customer with an expected date of completion. This process can take up to 3 weeks to complete.

Once the admin is notified that the set-up is complete, the login page will have the option for users to login via SSO:

Step 4: Testing & Troubleshooting

Immediately after the process is completed, make sure to test logging in via SSO. Read this article should you experience any issues with this new login option.

Did this answer your question?