The Customer Single Sign-On (SSO) Challenge

Customer experience plays a crucial role in Digital Transformation (DX). In competitive markets, consumers can easily switch to a competitor’s offering if they are frustrated with the usability of an App. Even the smallest of issues with an App usability can derail the customer experience. These obstacles represent challenges for the organisation to overcome in order to provide the best web and mobile experience and retain customers.

Getting the customer experience right requires organisations going through digital transformation to develop solutions that have the right balance between security and customer experience. This article is one in a multi-part series meant to tackle some of the key challenges faced by enterprises big and small while going through their digital transformation. Throughout this article and based on first-hand experience, I will walk you through one of key challenges of getting that right balance, which is The Customer Single Sign-On (SSO) Challenge and how to overcome it.

The Business Scenario

Consider a business scenario where the organization (for example: Initech Corp from Office Space movie ??) has a Mobile App. Initech Corp wants to introduce a new feature to enable their customers to retrieve media assets (images, videos, etc.) using Initech Corp Mobile App. The Initech Corp project team decides that offloading customers media assets to Amazon AWS Simple Storage Service (S3) is the best solution option for the best customer experience and best quick turnaround for developing the feature in-terms of speed-to-market.

In the above solution, customers access Initech Corp data center to retrieve and update their account details (Name, address, preferences, etc.) and AWS S3 for the media assets (e.g. profile face photo, etc.) using Initech Corp Mobile App. Because the consequences of a data breach are immediate to Initech’s reputation, share value and customer loyalty, security team would argue that keeping this type of data in the cloud - Personal Identifiable Information (PII) - is insecure, especially when stored on a publicly accessible service such as Amazon’s Simple Storage Service (S3). They would also argue that the same functionality can be achieved storing data on-premises where it is “more secure”.

The recommendation from security team are likely to hurt customer experience and would take lots of time to implement. Security team usually argue it is a bit of a pain but it is secure. Project team and business owner would have a different view leaning toward a more flexible security controls and cloud-based hosting to avoid hurting customer experience.

In the above situation, there are typically 3 possible outcomes:

1. The project team implements what security team wants and they end up with a secure Mobile App with a bit of a pain for customers in-terms of usability. They would end up also with stretched delivery timeline as hosting (including development of APIs to retrieve the media assets) would happen inside Initech Corp data centre.
2. The project team with support from business owner ignores security team advice and they go on with cloud-based hosting of media assets and the best they can do in-terms of security without affecting customer experience and they end up with an app which has a good customer experience but poor in-terms of security which makes the Initech Corp vulnerable to immediate risks.
3. The project team de-scopes the feature to be released in the future when Initech Corp capability changes in a way where they can have the right balance between security and customer experience and they end up with unhappy customer.

How to overcome the challenge? The Solution

What if there is a way to give the project team the right balance between security and customer experience and can be implemented quickly. Wouldn’t that be super awesome!.

Amazon AWS S3 has a simple web services (API) interface that you can use to store and retrieve any amount of data, at any time, from anywhere on the web. This means project team would save lots of time by leveraging a proven cloud-based simple media storage and retrieval capability.

In-terms of enabling customers to access their media assets securely, what we need to do is to link the customer's electronic identity between Initech Corp and AWS S3. Linking the customer's electronic identity and attributes in Initech Corp and AWS S3 is commonly known as Customer Federated Identity or Single Sign-On (SSO). In SSO terms, Initech Corp becomes the Identity Providers (IdP) and AWS S3 becomes the Application Provider (AP) on the architecture diagram. The SSO design here need to support secure and strict access to customers media assets (the media assets here are considered PII (Personal Identifiable Information)).

Looking at AWS capabilities in-terms of Identity Federation/SSO, one product really shines, which is the AWS IAM (Identity Provider feature) which gives the ability for an external identity to access AWS resources securely.

In this solution, we would be using AWS IAM Web Identity Federation, AWS S3, and AWS STS.

The customer experience is as per the below:

• The customer would login to Initech Corp Mobile App and get issued SSO token behind the scenes (JWT token).
• Then get to the landing screen (dashboard) where 4 APIs would be called, One to get the customer profile and the other two to Assume Identity Role and get temporary AWS token.
• Mobile App would use the JWT token issued when the customer logged in to access their account details (Name, address, preferences, etc.).
• Mobile App would use temporary token issued by AWS STS issued at the time of assuming identity role to get the customer Face Photo from S3.

The architecture diagram below outlines the solution components and the messages between components.

RFC Standards

For the solution above, we are only adopting the below RFC standards to achieve SSO between Customer APIs hosted inside Initech Corp data centre and AWS S3 APIs hosted on Amazon AWS data centre.

•  OpenID Connect Identity Layer Authentication flow and Discovery
•  RFC 2617 (Basic Authentication Flow)
•  RFC 7515 (JWS JSON Web Signature)
•  RFC 7519 (JWT JSON Web Token)
•  RFC 7517 (JWK JSON Web Key)

The 1 hour implementation

The steps below assumes you already have your Identity Provider (IdP) capability supporting OpenID Connect. I will be writing another articles to walk you through how to establish an IdP. You can subscribe to my blog to get notified when I do if you are interested.

The setup needed on AWS takes around 1 hour if not less and can be summarised in the following 6 steps:

1. On AWS IAM, create new Identity Provider of type OpenID Connect
2. Create New IAM role and call it OpenIDCustomerRole
3. In the role you have created above, configure trust relationship and appropriate conditions for the JWT token claims. This would be used for authorisation at the time of assuming the OpenIDCustomerRole by customers using the Mobile App.
4. Create S3 Bucket (encrypted) where you would place the customer photos. Have the media assets created inside folders that has the customer number as the name of the folder. This is necessary to allow customers to access only their media assets through an authorisation policy that matches customer id with the S3 folder name.
5. Create IAM Policy for AWS STS to allow only JWT token issued for certain set of audiences.
6. Create IAM Policy for S3 which would allow customers to access only their media assets

Conclusion

As you can see from the above, it is not that difficult to achieve good customer experience and in the meantime, maintain the highest security standard.

AWS IAM Web Identity Federation feature can be configured to allow access to several other services on AWS including DynamoDB where fine-grained authorisation is possible, easy and quick to implement. You can find other articles around security challenges faced by organisation during their journey into digital transformation at my blog here.

To access the same article on my blog click here.

Notice of Non-Affiliation and Disclaimer: The author of the article is not affiliated, associated, authorized, endorsed by, or in any way officially connected with any of the software product vendors (Amazon AWS) mentioned in this article, or any of its subsidiaries or its affiliates.