Panaya’s Web SSO (single sign-on) Journey

To Understand our Web SSO Journey, Let’s Start with a Bit of Context

Think about Panaya as Change Intelligence agent who can see and understand the impact of every potential change to your SAP, Oracle and Salesforce systems, so our customers can innovate intelligently, quickly and without fear.

Our SSO journey started with one of our customers requesting to use our E-signature solution over SAML. At that time, our implementation for such requests was to require re-authentication with PAOS protocol. This protocol was not supported by this specific customer IDP, so we decided to look for another way to implement it.

As part of an internal discussion with different divisions in the company, we came to the conclusion that our current SSO implementation is far from “customer friendly”. it has a real drawback and painpoint in that it requires down time for new certificate installations that are part of the SAML protocol.

That was bad bad and also… yes, bad!!!!!

One of the most widely used protocol at the time was Open ID Connect (and still is today). One of OIDC benefits is using tokens instead of certificates. We decided to leverate this approach.

OpenID Connect is built on the OAuth 2.0 protocol and uses an additional JSON Web Token (JWT), called an ID token, to standardize areas that OAuth 2.0 leaves up to personalize, such as scopes and endpoint discovery. It is specifically focused on user authentication and is widely used to enable user logins on consumer websites and mobile apps.

Our support team was “quite vocal” as far as making our solution user friendly, easier to implement and even self-managed by our customers.

OIDC is supported by all IDPs, and we were good to go for adopting it as our new SSO.
we used it for our new implementations, forcing re-authentication, as our e-signature feature and general integrations within other systems.

The final step was to make it easy to configure for our customers with self-service. That was released on Panaya latest version. 

Following is a simple diagram that demonstrates the different user flows of our login per the technology used by our client:

With the new SSO OIDC – Implementation of SSO for new or existing clients has become so much simpler:

The process starts with the client configuring his IDP to support Panaya’s SSO – Then they need to login to our self-service which enables them to check the configuration and ensure that the setting is working before letting end-users start using the SSO.  

The feedback that we are getting from our clients regarding the capability of testing SSO is outstanding – customers love it.  SSO reduces the complexity of implementation and integration of new SaaS cloud providers into their portfolio of services.

So it was a long journey….. it started from a simple customer requirement, that then manifested into analysis of our technology and solutions, and it then ended with providing better tools and user experience for our end customers.

What was our guide? It’s simple – Provide better user experience and superb functionality…

Our SSO journey might be at its end (for now), but the other bigger journey of improving our customer experience will probably never be over.

We continue to strive for a better user experience and functionality that can help the life of our customers and make their test management journey a bit better, more enjoyable and comfortable. We are Change Agents, sometimes we need to Change as well to get the job done.