Get an improved navigation experience with a Chrominium based browser.
Dismiss
Ruby Video
Talks
Speakers
Events
Leaderboard
Sign in
Talks
Speakers
Events
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Why You Should Avoid Identity Sync Like Wildfire? by Seyed Nasehi When we built our single sign-on service, we learned that syncing identity changes among applications can be deceptively complex. This is because we had to iteratively deploy the SSO service while supporting our existing applications that used the service. In this talk, we discuss lessons learned and recommendations on three key identity sync problems: 1) using editable fields such as email as an ID, 2) relying on unproven promises by standards such as SCIM, and 3) split-tenant situation. This talk will help developers avoid some pitfalls while building or working with an identity service. __________ Seyed M Nasehi is a software engineer at Cisco with a decade of software development experience. He's been building Ruby on Rails applications in the past 3 years to help customers who are using Cisco security products. His latest involvement was building a single sign-on service to be used by multiple security products within Cisco.
Date
Summary
Markdown supported
In the talk 'Why You Should Avoid Identity Sync Like Wildfire?', Seyed Nasehi presents insights from his experience developing identity services at Cisco. The presentation focuses on the complexities of synchronizing identity changes across applications, particularly highlighting three key pitfalls: 1) using editable fields like email as identifiers, 2) depending on unproven standards like SCIM, and 3) managing split-tenant situations. Nasehi shares two fictional scenarios involving developers Zoe and Chloe, who are tasked with building authentication services for their companies. Zoe's initial approach involved creating a single sign-on (SSO) service that replicated identity information across multiple applications. This led to significant challenges, including complications with user ID updates, identity replication, and the difficulties of maintaining synchronization when users changed their emails or accounts. Users experienced frustration as they could no longer log in seamlessly across services after specific updates were made. In contrast, Chloe took a different approach after learning from Zoe's mistakes. She utilized a centralized authentication system that eliminated the need for redundant identity synchronization. Chloe's design included straightforward mechanisms for user management across multiple organizations and services while maintaining a single source for authentication information. With her designs, user satisfaction improved as inter-service conflicts and mismatches diminished. The key conclusions from Nasehi's talk emphasize: - The importance of avoiding reliance on external standards unless they are widely adopted. - Centralizing authentication to reduce the complexities of identity synchronization. - Implementing practices that allow for seamless management of user access without compromising security or user experience. Overall, Seyed Nasehi's presentation provides valuable lessons for developers and engineers looking to improve identity service architectures by learning from common pitfalls in identity synchronization.
Suggest modifications
Cancel