Wind River
Rehauling Access Management
Rehauling Access Management
At a glance: How we made a clunky RBAC system more tolerable
WindRiver is a global leader in real-time operating systems software—the technology that powers space rovers, military jets, and other mission-critical machines.
I was part of a larger push across the organization to create a unified suite of products and design a centralized area to assign roles and permissions.
My Role
UI Design, Information Architecture
Team
Dylan- Architect + Supervisor
Scotty- Security Lead Developer team
Timeline
May - October 2024
Tools
Figma, Miro, Condens
Problem
Problem
CLI (Command Line Interface) won’t cut it
At the time, Wind River was using a command-line interface to manage Role-Based Access Control (RBAC), which is a system that restricts access to resources based on a user’s role within an organization.
Business Goal
There was a new security requirement from clients: organizational unit-based separation. i.e North America and Europe branches of an organization needed to be completely separated.
Like with most things, it comes down to the bottom line; if we don't re-haul the RBAC architecture to our client's standards, we are going to risk losing some of our largest customers.
There was a new security requirement from clients: organizational unit-based separation. i.e North America and Europe branches of an organization needed to be completely separated.
Like with most things, it comes down to the bottom line; if we don't re-haul the RBAC architecture to our client's standards, we are going to risk losing some of our largest customers.
There was a new security requirement from clients: organizational unit-based separation. i.e North America and Europe branches of an organization needed to be completely separated.
Like with most things, it comes down to the bottom line; if we don't re-haul the RBAC architecture to our client's standards, we are going to risk losing some of our largest customers.
User Problem
Users found the current access control system confusing, convoluted, and difficult to implement correctly. It was not centralized or standardized across all products and only accessible via CLI.
Specific issues include:
Lack of visibility into current permissions and roles.
Difficult to onboard new team members without strong CLI knowledge.
Risk of misconfiguration due to manual entry and lack of validation.
Time-consuming for administrators to manage permissions at scale.
Users found the current access control system confusing, convoluted, and difficult to implement correctly. It was not centralized or standardized across all products and only accessible via CLI.
Specific issues include:
Lack of visibility into current permissions and roles.
Difficult to onboard new team members without strong CLI knowledge.
Risk of misconfiguration due to manual entry and lack of validation.
Time-consuming for administrators to manage permissions at scale.
Users found the current access control system confusing, convoluted, and difficult to implement correctly. It was not centralized or standardized across all products and only accessible via CLI.
Specific issues include:
Lack of visibility into current permissions and roles.
Difficult to onboard new team members without strong CLI knowledge.
Risk of misconfiguration due to manual entry and lack of validation.
Time-consuming for administrators to manage permissions at scale.
Problem
Problem
Requirements
After discussing with various stakeholders, such as several product owners and the security team, we had the following additional requirements:
After discussing with various stakeholders, such as several product owners and the security team, we had the following additional requirements:
After discussing with various stakeholders, such as several product owners and the security team, we had the following additional requirements:
Discover
Discover
Cross-Team Collaboration
UX played a critical role in shaping the hierarchy and architecture of the new RBAC system. By collaborating closely with veteran members of the security team and studying industry standards, we helped define a structure that aligned with real-world mental models.
Research into how leading platforms designed their interfaces also informed a more intuitive and consistent user experience.
UX played a critical role in shaping the hierarchy and architecture of the new RBAC system. By collaborating closely with veteran members of the security team and studying industry standards, we helped define a structure that aligned with real-world mental models.
Research into how leading platforms designed their interfaces also informed a more intuitive and consistent user experience.
UX played a critical role in shaping the hierarchy and architecture of the new RBAC system. By collaborating closely with veteran members of the security team and studying industry standards, we helped define a structure that aligned with real-world mental models.
Research into how leading platforms designed their interfaces also informed a more intuitive and consistent user experience.
Discover
Discover
Personas
Our research team had extensive documentation on user types of our current product, based on company role observed from current users.
We knew that our solution needed to accomodate two primary personas;
Our research team had extensive documentation on user types of our current product, based on company role observed from current users.
We knew that our solution needed to accomodate two primary personas;
Our research team had extensive documentation on user types of our current product, based on company role observed from current users.
We knew that our solution needed to accomodate two primary personas;
Administrators would likely be day-to-day users, and would prefer high information density. Interviews with them showed that prioritize speed and efficiency, most actually preferring CLI because of this.
At the same time, we needed to keep the interface accessible to infrequent users such as managers and team leads.
Administrators would likely be day-to-day users, and would prefer high information density. Interviews with them showed that prioritize speed and efficiency, most actually preferring CLI because of this.
At the same time, we needed to keep the interface accessible to infrequent users such as managers and team leads.
Administrators would likely be day-to-day users, and would prefer high information density. Interviews with them showed that prioritize speed and efficiency, most actually preferring CLI because of this.
At the same time, we needed to keep the interface accessible to infrequent users such as managers and team leads.
Design
Format Exploration
We knew that tables were the most likely format. But due to the design system team doing updates on components, we could give proposals on potential different formats.
We knew that tables were the most likely format. But due to the design system team doing updates on components, we could give proposals on potential different formats.
We knew that tables were the most likely format. But due to the design system team doing updates on components, we could give proposals on potential different formats.
Tripartite Graph
Our security lead observed that managers often struggled to visualize which developers had access to which resources, since access was assigned through groups rather than directly.
This format was preferred by them because it allowed both layers—developers and their associated groups/resources—to be viewed simultaneously. However, it was an unconventional approach, not previously encountered, and posed significant implementation challenges.
Our security lead observed that managers often struggled to visualize which developers had access to which resources, since access was assigned through groups rather than directly.
This format was preferred by them because it allowed both layers—developers and their associated groups/resources—to be viewed simultaneously. However, it was an unconventional approach, not previously encountered, and posed significant implementation challenges.
Our security lead observed that managers often struggled to visualize which developers had access to which resources, since access was assigned through groups rather than directly.
This format was preferred by them because it allowed both layers—developers and their associated groups/resources—to be viewed simultaneously. However, it was an unconventional approach, not previously encountered, and posed significant implementation challenges.
"Master-Detail" Interface
This layout, though less commonly used in modern applications, enables quick viewing and comparison of individual items.
This layout, though less commonly used in modern applications, enables quick viewing and comparison of individual items.
This layout, though less commonly used in modern applications, enables quick viewing and comparison of individual items.
Pros
Efficient to navigate, especially between items
Select different items without loosing context
Pros
Efficient to navigate, especially between items
Select different items without loosing context
Pros
Efficient to navigate, especially between items
Select different items without loosing context
Cons
Non-Standard
Not existing pattern in design system
Less space to display information
Overload of information
Cons
Non-Standard
Not existing pattern in design system
Less space to display information
Overload of information
Cons
Non-Standard
Not existing pattern in design system
Less space to display information
Overload of information
Challenges
Challenges
Tackling Technical Complexity
A huge part of RBAC was the initial setup. Currently that was a largely manual/labour intensive process. Installation itself often took months for a client to complete, one client told us their IT teams were “dreading” the setup related to security and permissions.
LDAP Integration was a huge part of what we needed to consider. The interface in this case study only concerns maintenance, but determining how to efficiently assign roles across hundreds or thousands of users is crucial.
Additional challenges we faced were:
A huge part of RBAC was the initial setup. Currently that was a largely manual/labour intensive process. Installation itself often took months for a client to complete, one client told us their IT teams were “dreading” the setup related to security and permissions.
LDAP Integration was a huge part of what we needed to consider. The interface in this case study only concerns maintenance, but determining how to efficiently assign roles across hundreds or thousands of users is crucial.
Additional challenges we faced were:
A huge part of RBAC was the initial setup. Currently that was a largely manual/labour intensive process. Installation itself often took months for a client to complete, one client told us their IT teams were “dreading” the setup related to security and permissions.
LDAP Integration was a huge part of what we needed to consider. The interface in this case study only concerns maintenance, but determining how to efficiently assign roles across hundreds or thousands of users is crucial.
Additional challenges we faced were:
Bulk Actions
Although not included in the initial rollout of the new RBAC system, bulk actions needed to be considered early to ensure smoother integration in future updates.
Although not included in the initial rollout of the new RBAC system, bulk actions needed to be considered early to ensure smoother integration in future updates.
Although not included in the initial rollout of the new RBAC system, bulk actions needed to be considered early to ensure smoother integration in future updates.
Scalability for Large Orgs
The system had to support complex org structures—multiple divisions, thousands users—methods to manage these, and documentation needed to be created. Additionally, scalability to include bulk actions needed to be included.
One significant point of discussion was how "super" admins would be able to manage users and resources that crossed multiple organizational units. Should they have a centeralized interface, or require separate accounts for each?
The system had to support complex org structures—multiple divisions, thousands users—methods to manage these, and documentation needed to be created. Additionally, scalability to include bulk actions needed to be included.
One significant point of discussion was how "super" admins would be able to manage users and resources that crossed multiple organizational units. Should they have a centeralized interface, or require separate accounts for each?
The system had to support complex org structures—multiple divisions, thousands users—methods to manage these, and documentation needed to be created. Additionally, scalability to include bulk actions needed to be included.
One significant point of discussion was how "super" admins would be able to manage users and resources that crossed multiple organizational units. Should they have a centeralized interface, or require separate accounts for each?
LDAP & Database Connection
Connecting to LDAP and internal databases had to be simplified, with clear guidance and error handling to avoid technical bottlenecks.
Connecting to LDAP and internal databases had to be simplified, with clear guidance and error handling to avoid technical bottlenecks.
Connecting to LDAP and internal databases had to be simplified, with clear guidance and error handling to avoid technical bottlenecks.
Result
Final Design
Ultimately, we ended up going with the more “standard” layout, for ease of implementation and simplicity.
Ultimately, we ended up going with the more “standard” layout, for ease of implementation and simplicity.
Ultimately, we ended up going with the more “standard” layout, for ease of implementation and simplicity.
Retrospective
Where are we now?
By the end of my co-op term, all designs were approved, although implementation wouldn't start until nearly a year later.
By the end of my co-op term, all designs were approved, although implementation wouldn't start until nearly a year later.
By the end of my co-op term, all designs were approved, although implementation wouldn't start until nearly a year later.
Final Thoughts
The majority of time was spent on determining the many intricacies and specific scenarios of implementing RBAC.
Such as:
What would the viewer, editor, and lead role be able to change/view depending on the resource?
How do we handle role hierarchy? Would higher roles inherit all permission from lower roles?
How would a user give permissions to someone for a specific resource, but not the entire project?
How do we manage temporary access?
And so on.
RBAC might seem like a dry topic to some, but I genuinely enjoyed navigating its complexities and collaborating across teams. It was a valuable learning experience, and I’m grateful it was one of the key projects I contributed to during my time at Wind River.
The majority of time was spent on determining the many intricacies and specific scenarios of implementing RBAC.
Such as:
What would the viewer, editor, and lead role be able to change/view depending on the resource?
How do we handle role hierarchy? Would higher roles inherit all permission from lower roles?
How would a user give permissions to someone for a specific resource, but not the entire project?
How do we manage temporary access?
And so on.
RBAC might seem like a dry topic to some, but I genuinely enjoyed navigating its complexities and collaborating across teams. It was a valuable learning experience, and I’m grateful it was one of the key projects I contributed to during my time at Wind River.
The majority of time was spent on determining the many intricacies and specific scenarios of implementing RBAC.
Such as:
What would the viewer, editor, and lead role be able to change/view depending on the resource?
How do we handle role hierarchy? Would higher roles inherit all permission from lower roles?
How would a user give permissions to someone for a specific resource, but not the entire project?
How do we manage temporary access?
And so on.
RBAC might seem like a dry topic to some, but I genuinely enjoyed navigating its complexities and collaborating across teams. It was a valuable learning experience, and I’m grateful it was one of the key projects I contributed to during my time at Wind River.
Let's start creating together
© Amber Zhuang 2025. All Rights Reserved.
Let's start creating together
© Amber Zhuang 2025. All Rights Reserved.
Let's start creating together
© Amber Zhuang 2025. All Rights Reserved.