Code Less, Achieve More: Disney+ Hotstar’s Approach to Modern Access Control

Photo by Helena Lopes on Unsplash

Introduction

In the complex organizational application landscape, internal tools like monitoring dashboards, IT service portals, and content management systems are common. The widespread use of service-to-service (S2S) calls is also prevalent in the microservices era. However, ensuring AAA security for these tools is challenging due to multiple teams’ involvement. Despite the option to integrate third-party Identity Providers (IDPs) like Okta or Google, developers face a steep learning curve dealing with IDP documentation and the complexities of authentication and authorization protocols. Moreover, developers often hesitate to prioritize authentication and security, perceiving them as separate from core business values.

To address this challenge, we created IAuth, a low-code platform at Hotstar. IAuth empowers applications to achieve AAA security with minimal developer effort, eliminating the need for extensive security expertise. It quickly gained traction within Disney+ Hotstar and received considerable acclaim from 50+ applications. This blog explores the journey behind the creation of IAuth.

Before IAuth

Before implementing IAuth, our internal applications had a fragmented and disorderly authentication framework. Different applications used various IDPs like Google, Okta, and Disney’s internal IDP (MyID). Some applications even relied on their own username and password mechanisms. Diagram 1 illustrates this scenario.

Diagram 1. Chaotic Authentication

Authorization added further segregation and fragmentation. Diagram 2 shows that applications independently built their authorization mechanisms. Some first-party applications used subjects within their service code (Case 2), while others stored permissions in the IDP using user groups and implemented logic in the OAuth protocol flow (Case 1). Third-party applications relied on its built-in mechanism and the IDP provided by the third party for permission controls (Case 3). For S2S calls, certain developers shared a hard-coded token between the caller and callee, embedding it in the HTTP header (Case 4).

Diagram 2. Chaotic Authorization

This fragmented and disorderly nature presents lots of issues:

• Administrative Overhead: IT administrators struggle with managing dispersed employee accounts across multiple IDPs and handling user permissions on individual application dashboards, amplifying the challenge as the number of applications and users grows.
• Security Monitoring Hurdles: The fragmented AAA security processes hinder effective monitoring, leaving the security team unaware of potential issues. Moreover, the absence of centralized auditing logs, currently relying on service developers for construction, leads to a lack of comprehensive audit trails across multiple services which inhibits effective investigations into security incidents.
• Compromised Security Practices: Security standards may be compromised due to oversight from our developers. For instance, the reliance on a simple hard-coded token shared between service-to-service (S2S) calls, while straightforward, raises concerns about the overall security posture. Additionally, the redundancy of accounts caused by multiple IDPs can result in the persistence of employee accounts even after they have left the company, posing a risk of data leakage.
• Redundant Development and Complex Integration: Developers invest resources in duplicating AAA security, requiring additional work during IDP changes. Furthermore, integrating with diverse IDPs and authorization protocols presents challenges, demanding a deep understanding, secure implementation, and a balanced approach to requirements, security, and user experience.
• Reduced Resiliency and Fault Tolerance: Dependence on a single IDP raises concerns about resiliency and fault tolerance, as a disruption in the IDP affects all services and applications, highlighting the need for a more adaptive architecture.

After IAuth

IAuth, serves as a low-code internal platform, enabling applications to achieve AAA security through three simple steps:

1. Create your service via the IAuth Portal

Diagram 3. Create your service via the IAuth Portal

2. Integrate with IAuth SDK with a few lines of code

// 1. initiate SDK with your 
iauthClient = iauth.NewIAuth({
       ID:                 "YOUR-SERVICE-ID",
       Secret:             "YOUR-SERVICE-SECRET",
       PanicServiceToken:  "YOUR-PANIC-SERVICE-TOKEN",
       BlockPanicTokenDuringNormal: true | false,
})
        
// 2. apply SDK to your http middleware
router.Use(iauthClient.Middleware())

3. Set up permissions, roles and assignments via the IAuth Portal

Diagram 4. Set up via the IAuth Portal

Dive Deep

In the sections below, we will talk about some core features of IAuth.

IDP-agnostic Architecture

IAuth builds an IDP-agnostic Single Sign-On (SSO) architecture, enabling seamless compatibility with any IDP. This flexibility empowers service owners to choose the required IDP based on different needs, allowing organizations to do IDP migration without impacting any applications. Furthermore, IAuth can work as an account provisioning tool, aggregating and correlating accounts sourcing from all IDPs.

Diagram 5. IAuth IDP-agnostic Single Sign-On Architecture

In Diagram 5, we illustrate the process of an employee accessing an application:

1. Initially, the employee initiates access to the application, which triggers redirection to the IAuth Login Center for authentication.
2. Subsequently, the employee undergoes a series of verifications through IDPs or IAuth itself.
3. After the verification, the request is redirected back to the IAuth Login Center
4. Upon successful authentication, the browser obtains a valid iauth token.
5. With this iauth token, the browser can seamlessly access applications without encountering repetitive login prompts.

Centralized Authorization and Full-Functional RBAC

IAuth provides a centralized and full-functional access control model for managing access in various scenarios. As illustrated in Diagram 6, this model is built based on RBAC (Role-Based Access Control), wherein each application is treated as a separate authorization space, instead of considering the entire applications of Hotstar as a single authorization space. Within each authorization space, traditional RBAC is applied. This model offers comprehensive control to IAuth owners while allowing application owners to retain control over their specific applications. Meanwhile, application owners have the flexibility to customize roles and permissions without limitations.

Diagram 6. IAuth Centralized and Full-Functional RBAC

Based on the powerful access control model, access to all applications in various scenarios can be controlled via the IAuth Policy Center. As illustrated in Diagram 7.

• First-party applications verify tokens and then check permissions based on policy data synchronized from the IAuth Policy Center (Case 1, 2).
• Third-party applications retrieve role information from tokens issued by the IAuth Login Center and utilize the built-in RBAC mechanisms to verify permissions. The RBAC mechanism pre-defines appropriate permissions for specific roles (Case 3).
• Additionally, for S2S calls between first-party applications, the caller acquires a service token from the integrated IAuth SDK and includes it in the requests sent to the callee (Case 4).

Diagram 7. IAuth controls access to all applications in various scenarios

Secure and Resilient Service Tokens

To address hard-coded token security concerns, IAuth develops a secure service token mechanism for S2S contexts. This mechanism combines short-term tokens with panic tokens (long-term tokens) for enhanced security and resilience. Short-term service tokens have a limited Time-to-Live (TTL) and automatic rotation to minimize token leakage impact. Panic tokens, with a permanent TTL, ensure consistent resiliency in failover scenarios without compromising security.

Diagram 8. Secure and Resilient Service Token Mechanism

In Diagram 8, after integrating the IAuth SDK, it maintains a periodically refreshed short-term service token. It also loads a panic service token from the application-dedicated Vault. During normal operation, the caller uses the short-term service token to access other applications. In the event of IAuth crashing, the caller switches to the panic service token. The IAuth SDK determines which token to provide based on IAuth’s status. Note that the panic service token is exclusively intended for failover scenarios. Once the callee receives the request, it verifies the token before responding. IAuth Policy Center manages and controls the permissions assigned to these tokens.

Transparent Auditing Architecture

IAuth utilizes a centralized authorization mechanism and implements a transparent and robust auditing architecture. This architecture requires no additional developer effort. Events generated by various components within the IAuth ecosystem are seamlessly transmitted to the IAuth Event Center through a resilient mechanism. This mechanism supports batch uploading, memory consumption control, time management, and retry capabilities to handle failures effectively. All events are stored in a standardized format and can be easily queried through IAuth dashboards, providing a convenient and centralized approach to monitor and analyze system activities.

Summary

By utilizing IDP-agnostic SSO, centralized authorization, full-functional RBAC access model, secure and resilient service tokens, and transparent auditing, IAuth simplifies AAA security, boosts productivity, and enhances overall security. Our future goal is to explore a zero-trust solution leveraging IAuth’s capabilities.

Excited about disrupting the OTT landscape at never-seen-before scale? Check out: https://careers.hotstar.com/