Single Sign On FAQs

Since Prolaborate is not IDP initiated, can we disable the Prolaborate icon’s visibility in Okta?

Yes, you can hide the Prolaborate application icon in Okta. This will not have any impact on the Prolaborate’s Single Sign-On capabilities.

Is it necessary to upload the Signature Certificate in Okta for Prolaborate’s SSO configuration?

Uploading the certificate to OKTA is not required. However, we recommend uploading the signature certificate as it adds a level of security and authentication.

Once we have Azure AD SSO configured can we have a redirect so that no one ever gets this login page?

Prolaborate V4.5 and later versions offer a feature that allows for the customization of the login screen specifically for SAML users. With this feature, you will have the capability to hide the login credential fields for all SSO users. To know more about this feature, have a look at the documentation here.

How to Configure SAML Group with Prolaborate?

Integrating your SAML groups with Prolaborate user groups is an important step in ensuring seamless access for users. The steps below detail the configuration process:

• Creating Groups in IDP Provider:
  Firstly, groups containing associated users must be created in your IDP provider.
• Creating Groups in Prolaborate:
  Subsequently, create an equivalent number of groups in Prolaborate that match your IDP groups.
• Access Control Profile Configuration:
  Navigate to the ‘Access Control Profile’ menu in Prolaborate. Here, you will have to create profiles for role-based access in the Prolaborate SAML application.
• User Group Allocation:
  Within the ‘Create Access Control Profile’ page, designate the correct user groups. This ensures that users from the SAML groups are allocated appropriately.
• For more insights into the ‘Access Control Profile’ menu, you can refer to this link.
• Linking SAML User Groups:
  Upon completion of the previous step, link the SAML User Groups to their corresponding profiles.
• For a detailed guide on connecting role-based access with SAML user groups, please refer to this link

Troubleshooting: User logging in with SSO credentials redirected back to Portal Login Page

Description:
When attempting to Login with SSO, the users are directed to the SSO site to enter their login credentials. Upon successfully logging into the SSO site, Portal redirects users back to login page instead of granting access to the platform.

This essentially means:

• User clicks “Login with SSO.”
• User is redirected to the SSO site’s login page.

• After a successful login at the SSO site, the user is, unfortunately, redirected back to the EA SaaS login page.

Potential Causes & Solutions:

Case 1. Incorrect Attribute Mapping

• Cause: Incorrect configuration in the “Attribute Mapping” sections on the “SAML Single Sign-On” page within Prolaborate may cause such issue. Any errors here might prevent users from accessing Prolaborate and redirect them back to the login page.
• Solution: To resolve this, ensure that the appropriate attributes are correctly configured in the Attribute Mapping sections of both Prolaborate and the Identity Provider pages.

Case 2. Invalid or Expired .PFX Certificate

• Cause: We must analyze the debug log. From the log entries, we could identify whether the .PFX certificate file has expired. Here’s a snippet from the logs showing that the .PFX certificate used for SSO has expired. To analyze this case, we may request the debug logs for the investigation from our customers.

2023-05-09T10:55:37.3695425+02:00 [DBG] (ComponentSpace.Saml2.Certificates.CertificateValidator) The certificate expired on 2019-11-29 16:05:00.

• Solution: This issue can be resolved by uploading a valid SSL certificate. Additionally, ensure that the correct password for the SSL certificate is entered.

Troubleshooting: “Permission Denied” error when logging in with SSO

Description:
When a user tries to login with SSO, the user is landed on an error screen showing Permission Denied.

This issue typically occurs when the SAML group-based restriction is enabled, and the user is not there in the group otherwise the group is not linked with its respective Access Control Profile.

Potential Causes & Solutions:

1. Group Claim not configured in the SAML settings page.

• Cause: When the Group claim is not configured in the SAML settings page in both Prolaborate and your chosen Identity Provider (Azure AD, IBM, Okta, etc.,).
• Solution: To address this issue, ensure that you include the Group claim in Prolaborate’s SAML settings page under Attribute Mapping.

While the Attribute Mapping is typically preconfigured to default settings, for Identity Providers like Azure AD, it’s essential to switch to a custom configuration. This allows you to configure the claim names as needed.

2. SAML group not linked with its respective access control profile in Prolaborate

• Cause: When the SAML group is not properly linked with its corresponding Access Control Profile, users encounter a “Permission Denied” error in Prolaborate. When the SAML group-based restriction is active, Prolaborate restricts access for users who belong to SAML groups not linked with Access Control Profiles.
• Solution: This can be addressed by following the steps outlined below,
  1. Navigate to Menu->SAML Single Sign On.

2. In the Access Control Profile section, click on the drop down and select the desired Access Control Profile and also select the SAML group.

3. In SAML Group field, enter the respective SAML Group name and click save.

Finally, if you need to include additional profiles click on the “Add” button and do the selections as mentioned in above steps.

3. Absence of User in Corresponding SAML Group

• Cause: The user will get “Permission denied” when the user is not part of the corresponding SAML group. Enabling SAML group-based restrictions in Prolaborate, results in a “Permission Denied” error if the user is not a member of the SAML group that has the required permissions to access Prolaborate.
• Solution: Add the user to the respective SAML Group and make sure that the Group has all the necessary permissions to access the Prolaborate application.

We hope this article helps simplify your SAML configuration process with Prolaborate. For further assistance, don’t hesitate to reach our support team.