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

🚀 PermiForce: The Missing Security Layer for Azure DevOps PRs 🔐

Sick of unwanted PRs and unauthorized code slipping into your critical branches? Take back control!

Meet PermiForce — your bulletproof PR gatekeeper! 🔥

Built for the Permit.io Authorization Challenge, PermiForce brings fine-grained, role-based PR approvals directly into your Azure DevOps pipelines.

✅ Dynamic Permission Checks

✅ Real-Time Policy Enforcement

✅ Environment-Specific Controls (QA, UAT, Prod)

✅ Audit Trail for Full Compliance

✅ Low-Code Dynamic Integration with Azure Pipelines

🔐 Powered by Permit.io, PermiForce locks down your CI/CD like never before.

🛠️ What I Built

PermiForce transforms static pipeline permissions into dynamic, intelligent access control — enforcing "who can approve", "where they can deploy", and "when" based on real-time roles and policies.

Key Features:

• Role-Based Access Control (RBAC): Enforces permissions based on user roles, preventing unauthorized deployments.
• Dynamic Policy Enforcement: Utilizes Permit.io's policy engine to evaluate permissions in real-time.
• Environment-Specific Controls: Differentiates access rights across environments (e.g., QA, UAT, Prod).
• Integration with Azure DevOps: Seamlessly integrates with Azure DevOps pipelines for automated enforcement.

📝 Comparison: Azure DevOps vs. Permit.io

Why Permit.io?

• Azure DevOps lacks precise, dynamic PR-level access control.
• Permit.io fills the gap by providing granular role-based permissions, streamlined compliance tracking, and enhanced security for DevOps workflows.

👥 User Roles and Permissions

🧾 Detailed Permission Matrix

🧪 Testing the System

To test, I created USER_NAME variable to simulate different users but these can be dynamic through azure pipelines as well.

1. Test as Developer

   # Set pipeline variable
   user_name: [email protected]
   # Expected Results:
   - Can create PR to QA ✅
   - Cannot create PR to UAT ❌
   - Cannot create PR to PROD ❌

1. Test as Team Lead

   # Set pipeline variable
   user_name: [email protected]
   # Expected Results:
   - Can approve QA/UAT PRs ✅
   - Cannot approve PROD PRs ❌
   - Cannot create QA PRs ❌

1. Test as Release Manager

   # Set pipeline variable
   user_name: [email protected]
   # Expected Results:
   - Can approve all PRs ✅
   - Can create PRs to any branch ✅

🎥 Demo

🔗 Watch the full demo video here: Loom Video

The demo showcases:

• Setting up the Variable Group to securely store the Permit.io API key.
• Creating a PR and triggering the pipeline.
• A quick walkthrough of Permit.io policies.
• Simulating PR access checks using different users (e.g., alice-dev).
• Observing how PR approvals are enforced based on user roles.

Note: This project is for demonstration purposes only. The Permit.io policy server is locally hosted; therefore, the pipeline won't function as intended without the local server setup.

📂 Project Repository

• 📘 Documentation & Overview: GitHub Repository

• 🛠️ Pipeline YAML Files: Azure DevOps Repo
  dev.azure.com

Important: The GitHub repository contains comprehensive documentation and architectural details. The actual pipeline YAML configurations are maintained in the Azure DevOps repository.

🛤️ My Journey

As a Salesforce developer, I've often encountered challenges where CI/CD pipelines lack granular permission controls. Traditional setups allow any developer to push changes to critical environments, posing significant risks.

Through this project, I aimed to:

• Enhance Security: Implement a system where only authorized roles can approve and deploy changes.
• Leverage Policy-as-Code: Utilize Permit.io to define and enforce access policies dynamically.
• Improve Workflow: Streamline the deployment process while maintaining strict access controls.

Challenges Faced:

• Integrating Permit.io with Azure DevOps pipelines.
• Simulating different user roles within the pipeline.
• Handling API call failures gracefully within YAML scripts.

Key Learnings:

• The power of combining policy-as-code with CI/CD pipelines.
• Advanced YAML scripting techniques in Azure DevOps.
• The importance of dynamic access control in modern DevOps practices.

🔐 Using Permit.io for Authorization

To implement dynamic, fine-grained access control in our Azure DevOps pipelines, we integrated the Permit.io Node.js SDK. This approach allowed us to perform real-time permission checks based on user roles and actions, ensuring that only authorized personnel can create or approve pull requests (PRs) to specific environments.

🚀 Integration Steps:

1. SDK Installation: We began by installing the Permit.io SDK in our project:

   npm install permitio

1. SDK Initialization: In our pipeline scripts, we initialized the SDK using our Permit.io API token:

   const { Permit } = require('permitio');

   const permit = new Permit({
     token: process.env.PERMIT_API_KEY,
     pdp: 'http://localhost:7000', // URL of the local PDP (Policy Decision Point)
   });

Note: The PERMIT_API_KEY is securely stored in Azure DevOps variable groups.

1. User Context Capture:
   
   The pipeline captures the user_name of the individual initiating the PR. This information is crucial for evaluating permissions.

2. Permission Check:
   
   Before proceeding with PR creation or approval, the pipeline invokes the check method:
   

   const decision = await permit.check(user_name, action, resource);

• user_name: Email of the user initiating the action.
• action: The action being attempted (e.g., create, approve).
• resource: The target environment (e.g., qa, uat, prod).

1. Decision Enforcement: Based on the response:

• If decision.allow is true, the pipeline proceeds.
• If decision.allow is false, the pipeline halts, and an error message is displayed.

This integration ensures that PR operations are strictly governed by the defined policies in Permit.io, enhancing security and compliance in our CI/CD workflows.

Here is the link to our permit-server.js

Thank you for exploring PermiForce! 🚀

Update: I had accidentally submitted this post from another account "shivamkapasia" earlier. It’s now correctly published here from my main Dev.to account "shivamkapasia0". Thanks for understanding!

Please do visit for Documentation & Overview: GitHub Repository

A special thanks to the Permit.io and dev.to teams for organizing this challenge and providing a platform to innovate in the realm of CI/CD security.