Permit Io Challenge Entry: Tool Access Panel

This is a submission for the Permit.io Authorization Challenge: Permissions Redefined

What I Built

This project is a lightweight Internal Tools Access Panel — a dashboard interface that securely routes employees to internal tools like HRMS, Sales CRM, or CI/CD pipelines, based on their role within the organization.

The problem it solves is twofold:

1. Over-permissioned access: Without RBAC, internal systems often expose all tools to every employee.
2. Complex onboarding: Managing access manually per user or embedding authorization logic deep in every tool becomes hard to maintain.

With this panel, companies can:

• ✅ Centralize internal tool access
• ✅ Restrict access to only the tools users need
• ✅ Offload role/policy management to Permit.io

Key Ideas:

• Simple Auth: Login is managed via a static credential list (for demo purposes).
• Dynamic Access: Tool access is determined by role-to-resource policies defined in Permit.io.
• Permission Enforcement: Each tool route validates access using Permit's PDP (Policy Decision Point).
• Scalable Setup: Easy to extend for SSO, real users, and dynamic resources.

This project is intentionally kept minimal and readable as an ideal entry point for developers exploring Permit.io in real-world role-based access control scenarios.

Demo

You can explore a working demo of the Internal Tools Access Panel here:
???? Live Demo

????️ Prefer a walkthrough?

This project demonstrates how to control access to internal tools based on user roles using Permit.io. Below are the key screens with explanations:

???? Home Page

This is the default route (/) that simply redirects to the login page.

???? Login Page

A simple login form (/login) where users can enter their credentials. The list of valid users is loaded from environment variables.

❌ Failed Login Attempt

When invalid credentials are entered, a clean error message is shown without redirecting or crashing the app.

???? Tools Page – Admin Role

After login, users are redirected to the tools dashboard (/tools). Admins see all tools: HR, Sales, and Pipelines.

???? Tools Page – HR Role

HR users see only the HR tool in the sidebar. This behavior is similar in other roles like pipelines only shown in developer role and sales funnel is shown in sales role.

????️ Tool Detail Page – HR

A detailed view under (/tools/hrms) with a description or feature set specific to HR workflows.

???? Tool Detail Page – Sales

Sales users access their dashboard under (/tools/sales_funnel), only if their role includes the sales tool.

???? Tool Detail Page – Pipelines

Dev or Admin users with pipelines (/tools/pipelines) access will see this view, often used for CI/CD or deployment tools.

Project Repo

Link: https://github.com/codanyks/internal-tool-access-panel

My Journey

This was my first time participating in a Dev.to challenge — and it turned out to be a proper rollercoaster. To begin with, I spent some time just exploring how others approached past challenges to get a sense of what's expected. Once I felt confident enough, I jumped into building a project. Ironically, right as I was about to submit it, someone else beat me to it with a very similar idea. Classic timing.

At that point, I realized two things: first, the submission needs to be deployed and working, and second, I'd need to get comfortable with tools like Vercel and Next.js — both of which I hadn’t used before. So I took a detour, experimented with deployments, and familiarized myself with the Next.js ecosystem.

To keep the project lightweight and focused, I skipped setting up a database and went with environment variables for handling login credentials and role mappings. I started by building the project entirely without Permit.io, as I had never worked with it before. The idea was to first get a fully working version using basic role-checking logic. Once everything was in place and functional, I replaced the internal authorization logic with Permit.io's enforcement.

This approach helped me learn at every step — from structuring a minimal but functional app, deploying with Vercel, and navigating the Next.js file-based routing system, to finally understanding how Permit.io fits into a real-world role-based access system.

The result is a small, clean, and working application that demonstrates access control using Permit.io — with a login flow, session handling, and role-based access to internal tools. It's intentionally simple to help others learn from it, just like I did.

The Pivot: From Hardcoded to Externalized Authorization

When I first implemented the role-based logic, everything was handled internally. I used environment variables to mock user credentials and roles, then used simple conditional checks across routes to restrict access. It worked — but it wasn't scalable, reusable, or maintainable.

Once the core project was up and running, I took a step back and integrated Permit.io to externalize the entire authorization layer.

Here's how that pivot made a difference:

1. Decoupling Logic from Code: With the initial setup, access control rules were baked directly into the code. Changing a role or access rule meant digging into handlers or components. With Permit.io, I could define roles, resources, and policies externally, and update them without redeploying or modifying the codebase.
2. Real-Time Policy Testing: Permit.io's UI let me simulate access decisions on the fly. I could ask questions like "Can HR view pipelines?" or "What resources can an Admin access?" without writing new test cases or reloading the app. This real-time feedback loop dramatically sped up iteration.
3. Centralized Control: Instead of scattering access logic across pages and routes, Permit.io acted as the single source of truth. This not only made debugging easier, but also offered better visibility into how access decisions were made.
4. Built-In Best Practices: By integrating Permit.io's SDK, I benefited from proven patterns like PDP (Policy Decision Point) evaluation, contextual attributes, and role inheritance — without having to build those systems myself.
5. Reduced Risk of Mistakes: In traditional role checks, it's easy to forget a condition or apply it inconsistently. With Permit.io, access logic is enforced uniformly, reducing the chances of human error during development or maintenance.
6. Focus on Business Logic: With authorization abstracted out, I could focus on the actual purpose of the project — showing users the right tools based on their role — without worrying about enforcement mechanisms.

In the end, this pivot wasn't just a requirement for the challenge — it was a valuable learning moment. It showed me how modern tools like Permit.io can cleanly separate concerns, simplify code, and create more secure, manageable systems.

Using Permit.io for Authorization

To integrate Permit.io for fine-grained authorization in this project, I decided to go through the CLI route to understand the developer experience better.

1. Setting Up Permit.io

First, I created an account at Permit.io and created a new project from the dashboard. Once inside, I navigated to the "API Keys" section and copied the dev environment key to use with the CLI.

I installed the Permit CLI globally using:

npm i -g @permitio/cli 

Then I logged in with the API key using:

permit login --api-key <YOUR_API_KEY> 

2. Initializing the Project

Next, I initialized the CLI setup using:

permit init 

This command walks you through an interactive flow to set up your authorization schema:

• It first asks how to set up policies:

I selected: "Create a simple policy"

• Then it asked to configure resources:

I provided: pipelines, hrms, sales_funnel

• Next, it prompted for actions: I entered: create, read, access

• For roles and permissions, it asked in the format:

role|resource:action|resource:action 

3. Creating Users

After defining policies, it asks to add data setup for users.

It gives two options:

• Interactively create users
• Generate users automatically

I selected: “Interactively create users”

I was prompted to enter the number of users (I chose 2) and then their IDs and roles:

• admin user
• newuser user

4. PDP Configuration

At the end of the init flow, it asks to configure the PDP (Policy Decision Point). It attempts to start a local PDP server (which uses Docker). However, I didn't have Docker configured locally, so I skipped this step and instead used the deployed PDP available in the Permit dashboard.

5. Cleanup Notes

Permit.io adds a few default roles like viewer and editor. I attempted to delete these using the CLI, but the command didn't return a confirmation. When I checked the dashboard, those roles were still present, so I manually deleted them there.