Managing access permissions is a critical aspect of application security, especially for large platforms like Discord. In a great blog, “Access: A New Portal For Managing Internal Authorization,” Elisa Guerrant, Security Engineer at Discord, details how they built “Access!” - a secure, accessible internal authorization portal.

This blog will discuss the importance of creating permission management systems that balance security and accessibility for all application users. It will also introduce "Permit: Elements," a set of prebuilt, embeddable UI components designed to further streamline and enhance permission delegation. Thus demonstrating how to improve the accessibility of your own authorization management system. Let’s dive in!

Authorization: Security First, Accessibility Second

Building and managing a system that can handle access permissions is a must for basically any application these days, especially one as large as Discord. With applications growing ever more complex and the reality of microservice-based architectures, ensuring that the right users have appropriate access to the right resources at the right times is a bigger challenge than ever.

When building authorization, especially considering it’s a feature mostly built in-house and requires a very large amount of effort to develop, developers tend to focus on building authorization that provides the required level of security and restrictions their app needs. This approach is great, but it comes with a catch—it often overlooks the importance of developer and user experience.

To understand why experiences are important in authorization, let’s talk about who uses our app.

Who Uses Our Application?

Every modern application consists of several levels of users. It’s never as straightforward as end-users and developers.

End-users interact with our application in multiple areas, each of which must be considered when designing our authorization layer. This includes what users can see in the application, ****which actions they can perform, and what data they can access.

App developers need a level of user permissions management that allows them to create and handle new policies, requests, and processes.

This obviously doesn't mean their access is unlimited, and it requires monitoring and management as well. Who decides what developers can access and what level of control they have over our application's authorization layer? More often than not, a specific person or group will be directly in charge (albeit reluctantly) of managing the application’s user and role management.

Depending on our application, there are more possible levels here. Internal Users who are members of our organization might need different levels of access, and some may need to manage and delegate access to end-users. Organizational Stakeholders, such as DevOps, RevOps, and AppSec teams, require access to specific parts of the application, as well as the ability to manage user roles and delegate access management to internal users.

How Do We Handle All These Users?

The prospect of creating all-powerful superusers is alluring to many developers. What can be more secure than directly calling all the shots yourself? And while that’s true to some extent, this approach backfires very quickly. If you, as a developer, are the person directly in charge of all user roles and permission management in your organization, you will very quickly realize the strain this will have on you and the entire R&D team as you turn into a bottleneck for the entire business operation.

Only one person/group can manage authorization for every user of your application? Great - it’s their full-time job now.

The opposite approach, delegating all power away from developers to other stakeholders, is often equally dangerous, as it can create a slow-moving, inefficient bureaucracy or an unstable, risk-filled environment.

What this means is that our authorization layer needs not only to provide a solid, secure basis for determining who has access to what within your application, but it must also be approachable and easy to understand. This is emphasized even further in Elisa’s blog, where she mentions the fact that 74% of all breaches involve the human element, with privilege misuse and stolen user credentials being two of the primary threats.

This is the direct result of developers’ tendency to focus on authorization being secure (which is great) while neglecting the need for it to be accessible (Which is bad).

As Elisa mentioned in her article:

“Policies designed to manage permissions tend to cause headaches for end-users and leave the decisions about “who can access what” in the hands of people who don’t have much information about the resources – often IT or Security”.

At Permit.io, we encounter this all the time. Many developers come to us because their homebrewed authorization solutions lack both developer and user experience.

Let’s see what Discord did to help solve these issues:

What Did Discord Do?

To address these concerns, the folks at Discord built an internal portal for staff to manage user permissions for their internal users, organizational stakeholders, and developers. Focusing on workforce identity (We’ll get to customer identity in a sec with Permit.io), they created it with the goals of being secure, transparent, and easy to use, and eventually made the tool publicly available and free to use.

What was their goal?

Discord uses Okta as its authentication solution for SSO. As they grew, they wanted the ability to further customize access controls for their employees. These were the goals they set for themselves:

• This tool needed to be security-focused and enforce the principle of least privilege.
• It needed to have an intuitive user experience that didn’t require staff to have deep knowledge of the access control tool or the systems being managed. This would help ensure the tool’s adoption within the company.
• The tool needed to be “self-serve” and allow delegation within their internal policies. As we mentioned previously, having IT or Security teams exclusively manage permissions would create a bottleneck in one particular organization and slow down the whole operation.
• Finally, they wanted a system that was transparent and discoverable. Users would be able to see what access they or their teammates have, what resources are controlled by the system, and what permissions they had in the past but have since expired. They should also be able to request access to resources freely, empowering them to troubleshoot their own permissions and solve issues through access requests.

After what Elisa describes as “weeks of development time and dozens of cups of coffee”, the Discord team ended up building “Access” - an RBAC-based solution for managing their internal user access control.

What features does this tool provide?

Let’s see what features Discord’s tool ended up providing and how these concur with the Best Practices for Effective User Permissions and Access Delegation:

• Delegated control: Each group or app has a set of owners who control membership and access related to that resource, ensuring each group or app has designated owners responsible for managing membership and access. This follows the best practice of having a primary admin or owner who manages permissions, preventing conflicts such as two admins being able to remove each other and ensuring that those with the most context handle permissions.
• Time-bounded access: This feature mitigates the risk of accumulating unnecessary permissions over time by allowing access to be set for predetermined periods.
• Access requests: Access requests enable users to discover and request necessary permissions, which are then reviewed by appropriate owners. This delegation supports a cascading model of permissions, ensuring that those with the best understanding of the needs grant permissions, balancing the load across different levels of the organization.
• Audit logs: Every user, group, and role in Access has a page viewable by all employees that shows complete membership and ownership history. These comprehensive audit logs allow all users to see complete membership and ownership histories. This transparency supports the generation of audit logs, which are crucial for tracking changes and understanding permission alterations at every level of the system. ‍

• Using classic policy models for ‘high-level’ authorization policies (e.g., RBAC, ABAC): Access was built based on an RBAC model, which helped ensure consistency and ease of understanding across the system, lowering the cognitive load on system managers and users.
• Building an easy-to-use UI: The intuitive and user-friendly interface built by the Discord team enables effective permission management. It makes permission management accessible and straightforward so that all users, regardless of technical expertise, can effectively manage and understand their permissions.

Implementing Accessible Authorization Elements

The tool built by Discord provides a masterful solution to the problem of effectively handling user permissions and access delegation. As mentioned before, we at Permit.io encounter this problem with our users all the time, and it spans beyond internal users.

Permit.io aims to provide a comprehensive solution for managing user permissions for all application users, from end-users to application developers, in a single, unified interface.

When we initially launched Permit, our goal was to provide developers with the building blocks needed (SDKs, gateway plugins, data updates) to integrate permissions into an application. This included a no-code UI for creating and managing permissions with RBAC, ABAC, and ReBAC support.

Permit.io’s permission management UI with RBAC, ABAC, and ReBAC policies, all together in one interface.

To further improve accessibility, we introduced “Permit Elements,” a set of prebuilt and embeddable UI components that provide fully functional access control. These components allow you to safely delegate permissions to your end users.

Permit Elements enable crucial permission management functionalities (such as User Management, Audit Logs, Access Requests, and Process Approval) to propagate through your user stack—from developers to internal users and end users, ensuring efficient and secure access management without bottlenecks.

By incorporating Permit Elements, you can enhance the accessibility and usability of your permission management system, ensuring that it is not only secure but also user-friendly and efficient.

Conclusion

Building an accessible permission management system is crucial for maintaining both security and efficiency in modern applications. Discord's innovative approach with its "Access" portal showcases how balancing security with user-friendly features can streamline operations and enhance overall security. By incorporating intuitive design and robust delegation capabilities, Discord has set a high standard for internal authorization management.

To further enhance your permission management system, we covered "Permit: Elements” - a set of prebuilt, embeddable UI components that offer fully functional access control. These components enable you to delegate permissions safely and effectively to your end users. By adopting such solutions, you can ensure that your authorization processes are not only secure but also accessible and efficient for all users.