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:
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
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 firstname.lastname@example.org would belong to the same user.
Is there any SCIM integration for de-provisioning 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?
Users visit their PostBeyond instance login page.
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).
Users are authenticated by the IDP by any methods they have set up for authentications.
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). If the user is signing in for the first time using SSO, we check to see if the user exists (based on the 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?
Manual Group Management: requires admins to manually group users after they have signed on for the first time.
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.
SAML Auto-sync: groups automatically sync-up according to customer directory - not yet completed by PostBeyond.
Master SSO: SSO for enterprise customers on multiple instances
SLO: Single log-out which forces users to be logged out of other apps authenticated by
After reviewing Understanding Single Sign-on (SSO) Through SAML and making the decision to move forward with implementing this login, it is time to set-up SAML SSO.