SSO Integration for Canto Cumulus

One of our DAM clients required single sign-on (SSO) for all internal users accessing Canto Cumulus hosted in an Amazon virtual private cloud (VPC), since they do not allow any incoming or outgoing LDAP traffic to and from the WAN. The goal was to provide immediate access once internal users are initially authenticated on their respective Windows workstations (“keys to the castle”). The problem we faced is that Canto does not provide an SSO connector yet … thus, such an integration had to be specifically developed.

We decided to use PingOne acting as the SAML service provider endpoint. The following diagram illustrates the complete integration that now allows our customers to simply click on a button or link in their intranet and immediately be connected to Cumulus Web Client without having to log in again.

This SSO integration is highly secure, as it validates the user details twice, once customer-side and a second time between Cumulus/AWS and PingOne. Furthermore, it still allows all other, regular Cumulus authentication options to be employed in parallel. That includes built-in users and AD-authenticated users, as the custom SSO Authenticator module is simply added as another Cumulus authentication module, but does not replace the existing Cumulus authentication modules. This gives customers a lot of flexibility to create mixed authentication scenarios. In fact, our particular customer uses all three authentication options:

1. Internal users connect via SSO
2. External agencies (not pictured in the diagram) connect via an AWS-hosted AD
3. Certain technical Cumulus users (like RoboFlow) connect as built-in users

So how does this SSO integration work?

1. A SAML token generated by our client’s federated service includes a re-direct URL.
2. Upon authentication completion, the return token (incl. all user metadata needed to verify the SAML token) is re-directed to the respective Cumulus web interface.
3. This data is transferred to the Cumulus Web Server as part of the login data.
4. The Cumulus Web Server connects to the PingOne server to verify the token.
5. Once verified, PingOne returns a SAML token with details (valid/not valid).
6. The Cumulus Web Server does a “Connect to Cumulus App Server” and posts a XML/JSON structure that the Cumulus App Server parses to authorize the user.
7. The Cumulus Server assigns user metadata and matches groups with roles based on the posted XML/JSON.

This only required very few integration parts which can easily be adapted to any future release of Cumulus, including:

1. A Cumulus Web Server “Token Handling Customization” that can be used to trigger a “Connect to Cumulus App Server” with PingOne’s SAML token handling.
2. A Cumulus App Server “Authenticator Customization” that will understand the XML/JSON structure posted by the Cumulus Web Server.

This integration is extremely flexible and can be adapted to fit additional requirements. If you are interested in this or other DAM customizations and/or integrations, please get in touch with us today.