DOCEBO / PingID SSO integration (OK with SAML, issues with OIDC, possible OIDC bug)

aroudnev · 2023-05-11T18:35:01+00:00

We run tests to integrate DOCEBO and PingID (PingOne and PingFederate in reality) for SSO and provisioning. Three scenarios tested. SAML, IdP is PO (PingONe for Enterprise, cloud Ping IdP). It worked out of the box with a very few specifics: - We was not able to use SAML_SUBJECT as UserID - I created user attribute and, CRITICAL, set up it’s type explicitly as urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified (it is IMPORTANT). - I could configure JiT provisioning. - Both IdP SSO and SP SSO works. - Other critical thing - need to copy/paste IdP metafile AFTER application configured, and copy some fields manually (ID). Wish list - we would like to be able to restrict local logins to a very few admin users only, so most users should use SSO only but admins can login local if required. And we would like to be able to provide metafile URL instead of copy-paste as this way we can update certificates. This is success, so PingID and DOCEBO integration works well (in SAML mode). 2. We tested OIDC and PingOne integration, as OIDC is easy to use and do not require periodic reconfigurations to update certificates. - SSO login OK in SP mode, do not work in IdP mode. - JiT provisioning works partially. We could map sub or email as Username but was not able to map any other claims at all, even if we tried different scopes and dofferent OIDC modes. Exactly the same IdP configuration, when working with Apache OIDC module, see all claims. And IdP SSO works with Apache (but no DOCEBO). So it works partially and we suspect bug in SP, IdP or both (likely both). To troubleshoot someone must be able to see logs on SP or on IdP or both. We can create test account and test SSO but need support from DOCEBO to resolve this mystery. 3. Tested OIDC and PingFederate (Ping On Premises IdP) integration. Mapping works. SP SSO works,. This combination do not have IdP initiated SSO. So, for SAML, it is extremely useful if SP can use URL and not ‘Upload’ for metafiles (as certs must be updated and this update is automatic only if url is used). In addition, when you enforce SSO, you want to keep backdoor access for a few admins so they can fix SSO if it broke, and it works much better if users can be restricted to some login method by default and exceptions can be done for some users.

aroudnev
Newcomer
0 replies

We run tests to integrate DOCEBO and PingID (PingOne and PingFederate in reality) for SSO and provisioning.

Three scenarios tested.

SAML, IdP is PO (PingONe for Enterprise, cloud Ping IdP). It worked out of the box with a very few specifics:
- We was not able to use SAML_SUBJECT as UserID
- I created user attribute and, CRITICAL, set up it’s type explicitly as urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified (it is IMPORTANT).
- I could configure JiT provisioning.
- Both IdP SSO and SP SSO works.
- Other critical thing - need to copy/paste IdP metafile AFTER application configured, and copy some fields manually (ID).

Wish list - we would like to be able to restrict local logins to a very few admin users only, so most users should use SSO only but admins can login local if required. And we would like to be able to provide metafile URL instead of copy-paste as this way we can update certificates.

This is success, so PingID and DOCEBO integration works well (in SAML mode).

2. We tested OIDC and PingOne integration, as OIDC is easy to use and do not require periodic reconfigurations to update certificates.
- SSO login OK in SP mode, do not work in IdP mode.
- JiT provisioning works partially. We could map sub or email as Username but was not able to map any other claims at all, even if we tried different scopes and dofferent OIDC modes. Exactly the same IdP configuration, when working with Apache OIDC module, see all claims. And IdP SSO works with Apache (but no DOCEBO).

So it works partially and we suspect bug in SP, IdP or both (likely both). To troubleshoot someone must be able to see logs on SP or on IdP or both. We can create test account and test SSO but need support from DOCEBO to resolve this mystery.

3. Tested OIDC and PingFederate (Ping On Premises IdP) integration. Mapping works. SP SSO works,. This combination do not have IdP initiated SSO.

So, for SAML, it is extremely useful if SP can use URL and not ‘Upload’ for metafiles (as certs must be updated and this update is automatic only if url is used). In addition, when you enforce SSO, you want to keep backdoor access for a few admins so they can fix SSO if it broke, and it works much better if users can be restricted to some login method by default and exceptions can be done for some users.

Reply

Still haven't found what you're looking for?

Sign up for Docebo Community

Log in to Docebo Community

Scanning file for viruses.

This file cannot be downloaded