Lotte ON's Journey to Adopting Integrated Authentication (Okta)

Lotte ON had accounts scattered across more than 50 in-house systems, and operated ETL, LDAP, and group company SSO separately, resulting in password synchronization delays, security risks from individual management, and increased operational costs due to multiple interfaces. The existing AS-IS solution and MS SQL also reached EOS status, making it difficult to respond to failures, and this prompted a review of adopting an IAM (Identity and Access Management) solution.

Okta is a cloud-based IAM that provides Single Sign-On, Universal Directory, Multi-Factor Authentication, and Lifecycle Management. Lotte ON selected Okta based on domestic and international references and evaluations from the Gartner Access Management report.

In the early stages of adoption, existing MS SQL data was migrated to Okta, internal systems were registered as applications, and account creation/deactivation automation and daily batch integration were configured according to LCM policy. However, two limitations emerged during the POC process.

• Password integration not possible: Okta cannot directly provide encrypted passwords externally, making it difficult to connect the group account management system in the same way.
• Organizational hierarchy not supported: Okta alone could not represent the organizational chart hierarchy structure that the existing system used.

To solve this problem, instead of relying on Okta alone, a proprietary account management system was built in front of it. Django was introduced to quickly equip the system with authentication, permission management, ORM, and session management features, providing the following API-centric functions.

• API calls that simultaneously update Okta and the group account management system when passwords change
• An organization API reflecting the existing system's organizational hierarchy
• A real-time user data lookup API

Application integration was organized into four approaches.

1. IN (Integration Network): Utilizing Okta Application Templates
2. SAML: Integration with vendors supporting SAML 2.0
3. SDK: Simple connection via SDK for supported languages/frameworks
4. API: Direct implementation of the OIDC flow when SDK is not possible

SaaS and new systems were easily connected via IN/SAML, but existing systems mainly implemented SSO through the API method. The flow is: the user is redirected from the app to Okta's /authorize, and after Okta authentication, the app receives an authorization code and passes it to /token to obtain an ID Token and Access Token. The app then stores the Access Token and allows the user access to the service.

Sessions had to be managed independently by Okta and each app. This was because if one session ended first, unnecessary re-logins could occur, or conversely, short sessions could worsen user experience. Lotte ON applied the following policy to balance security and convenience.

• Maximum Okta Global Session Lifetime: 1 day
• Maximum Okta Global Idle Time: 3 hours
• Okta Global Session Cookies Persist Across Browser Sessions: Disabled

After adoption, the following effects were achieved: up to 5 hours saved in password integration time, cost savings from switching from Google/Lotte OTP to Okta Verify, and cost savings from eliminating the ETL system. Going forward, plans include applying workflow automation and API-based self-service more broadly to further automate account management and operational tasks.