Single Sign On with Okta

Photo by Scott Graham on Unsplash

At a company I worked for, we allowed our customers to measure their customer experience and provide actionable insights including predicting future behaviors. With Surveys being the primary tool for collecting user feedback, we offered a portal to customer experience analysts and managers to get the insights. As a part of our tech transformation starting with migrating completely to AWS and launching a new analytics Portal that was powered on top of our new micro services architecture, we had to solve the problem of access

The Quick Access & Secure Authentication Problem

Before speaking about the authentication & access problem let me give context on our customers & user base. Our customers were major retailers who had many touch points and presence both digitally and in brick & mortar stores. Surveys were typically launched for various touch points to measure customer experience for different touch points and hence would typically require different user groups to be able to see insights on different touch points. Especially on the store side they also had a need to quickly allow large groups of users access to these insights that we were providing. All of these users would be accessing our multi tenant SAAS portal

Our legacy portal had struggled with providing quick access. While we were primarily a SAAS offering, ironically enough, our user management system was managed by our Support team. We had attempted Single Sign On (SSO) before and built a Shibboleth based SAML access but once again it required significant manual user provisioning since our legacy solution did not support Just in time provisioning (JIT). Finally onboarding a new customer required development since while all our customers desired & supported a SAML federation, we did not have base features for managing certificates, key exchanges and other SAML configuration. Thus with our new portal & tech strategy, we knew we kept the following goals for our authentication & single sign on system

• It should support federation and non federation use cases
• Support industry standard protocols for federation with SAML 2.0 & OIDC being top of the list
• Superior Configuration to support our SAAS platform with ease of configuration & on boarding
• Support for web & mobile devices including Native apps
• APIs to support deep integration from our portal
• Compliance with regulations such as HIPAA and FedRamp to allow us to comply with our customers in Healthcare & Government

Okta

We were clear that given our relatively small engineering team and the various core business priorities we were tackling, building a system that meets all the above objectives was going to require us to divert critical resources away from our core business priorities. Thus the Build vs Buy/Use decision was easy to make. But what providers would we go with?

We evaluated a ton of leaders in the space such as Ping Identity, One Login, etc but finally decided on Okta. Okta is a leader in Cloud Identity Management & as its tag line goes It powers the Identity for the Internet.

Okta checked all our objectives and in addition let us do the following

• At the core, a cost effective Universal Directory rich with integrations and extensibility features such as Expression Language
• Major upgrade into our User Management system with support for complex Password Policies, Lifecycle Management with SCIM Protocol Support, Improved Password Recovery Features, Multi Factor Authentication, etc
• Enable us to manage different password / lockout policy changes for our customers through Groups , Group Rules and Expre
• Overhaul of our own internal corporate user management with its Directory integrations
• Rich APIs to perform all forms of back channel integrations

Single Sign On

One of the key technical decisions we had to make was on the protocols to use. We wanted our tech stack to work with modern & open protocols and so we always found Open ID Connect (OIDC) to be the right thing to build our authentication solution on. Since OIDC is built on top of Oauth 2.0, this had synergies with our existing internal authentication mechanisms which we used between our own Single Page App (SPA) / Native Mobile Apps and our micro services backend — thus we wanted to keep that architecture intact. However within our customer base, SAML 2.0 was a frictionless option for achieving Single Sign On.

To solve this OKTA once again came to the rescue and our final solution is depicted below

Step 1: User went to our Analytics Portal or Native Mobile App which brought in the login screen as depicted below.

Our usernames were typically corporate email addresses such as john.doe@abc.com. Depending on the user name & specifically the domain name we would determine the Identity Provider to connect to. The Identity Provider itself was configured in Okta as SAML 2.0 External Identity Provider.

Step 2: From our Web Portal or Mobile App, we would then construct a OIDC authorization request to our Okta tenant, passing in the external IDP ID

Step 3: Okta would send a SAML Authn Request to the External IDP which in turn would authenticate the user. The IDP would if needed bring in their login screen for the user to login in case the user’s session had expired within their corporate network

Upon successful authentication, Okta receives a SAML Assertion which it uses to set the authentication context and in case of a new user provision the new user with relevant attributes (as received from the assertion) in its Universal Directory. This is a scenario of Just in Time (JIT) provisioning and Okta allowed us to configure this on a per customer / IDP basis

Step 4: Finally OKTA would use the authentication context to complete the Oauth2 authorization grant flow with our portal / mobile apps which in turn would use our backend to obtain an Oauth token. Our portal SPA and Mobile App would then use this token to make subsequent backend calls to render the analytical experience.

While the above depicts a Service Provider (SP) Initiated SAML flow, we also had customers with an Identity Provider (IDP) initiated flow.

User Management & SCIM

While Single Sign On was solved a major pain point for quick access, we also revamped our User Management system with the following

• All our users were seamlessly migrated to Okta’s Universal Directory
• For our customers that did not want to enable Single Sign On, their users continued to leverage logging into the Portal. But even for them we were able to very quickly provide a host of standard features like Password Recovery through Text, Password & Lockout Policies compliant with their Security Guidelines, Self Service User Management, Custom User Attributes & Claims for Authorizations
• With the help of the rich & developer friendly REST APIs, we were able to build back channel SCIM (System for cross-domain identity management) compliant directory & provisioning integrations

Authentication & Recovery Mechanisms

Finally our integration would be incomplete without providing a path for customers who did not want to invest in Single Sign On capabilities. With our micro services architecture in place, we were able to seamlessly integrate our OKTA APIs w/o having to build all these mechanisms ourselves and OKTA handled all the complexities of sending emails / SMS / Voice Call (and other MFA related communication & verifications). All this with us having full control over our user interface.

As depicted above, we were able to use the OKTA APIs for all the following aspects

• Authentication
• Text & Email Recovery
• User Provisioning / De provisioning
• Group Allocation & Managing Policies

Epilogue

In today’s enterprise, Single Sign On is a must have and support for industry standard protocols like SAML 2.0, OIDC and SCIM being vital. Building these features is complex and time consuming and hence using an Identity Provider like OKTA dramatically reduces the time to market. OKTA being a SAAS & Cloud Native solution means we get all the benefits of scale, availability & resilience for free.