基于IdentityServer4实现三种动态权限等级的技术咨询

Great question—handling granular permissions without hardcoding is a common challenge, and IdentityServer4 gives you the flexibility to build a dynamic system that covers all three levels you mentioned. Let’s break down a practical, maintainable solution that works across backend (API/middleware) and frontend (Razor) with zero hardcoded rules.

We’ll center the solution around a database-backed permission store (instead of hardcoded roles/policies) and extend IdentityServer4’s claims-based authorization to handle each permission type.

1. Page-Level Permission (Client/Role-Specific Access) #

Backend Implementation #

• Dynamic Permission Store: Create a PagePermissions table with columns like PermissionId, PageRoute, RoleName, ClientId (to restrict access per client app).
• Custom Policy Provider: Replace IdentityServer4’s default policy provider to load policies dynamically from the database, instead of using hardcoded [Authorize(Roles="Admin")] attributes:

  public class DynamicPolicyProvider : DefaultAuthorizationPolicyProvider
  {
      private readonly IPermissionService _permissionService;
  
      public DynamicPolicyProvider(IOptions<AuthorizationOptions> options, IPermissionService permissionService) 
          : base(options)
      {
          _permissionService = permissionService;
      }
  
      public override async Task<AuthorizationPolicy> GetPolicyAsync(string policyName)
      {
          // Fetch policy rules from the database
          var pagePolicy = await _permissionService.GetPagePolicyAsync(policyName);
          if (pagePolicy != null)
          {
              var policyBuilder = new AuthorizationPolicyBuilder();
              policyBuilder.RequireClaim("role", pagePolicy.AllowedRoles);
              // Add client restriction if needed
              policyBuilder.RequireClaim("client_id", pagePolicy.AllowedClients);
              return policyBuilder.Build();
          }
          // Fallback to default policies if no dynamic match
          return await base.GetPolicyAsync(policyName);
      }
  }
  

• Register the Provider: In your startup code, replace the default policy provider:

  services.AddSingleton<IAuthorizationPolicyProvider, DynamicPolicyProvider>();
  

• Apply Policies: Use [Authorize(Policy = "/Admin/Client")] on controllers/Razor pages, where the policy name matches the PageRoute value in your database.

Frontend (Razor) Implementation #

• Dynamic Navigation Component: Build a NavigationViewComponent that fetches allowed pages from an API endpoint (which checks the user’s claims against the PagePermissions table) and renders only accessible links:

  @foreach (var page in Model.AllowedPages)
  {
      <li class="nav-item">
          <a class="nav-link" asp-page="@page.Route">@page.DisplayName</a>
      </li>
  }
  

• Conditional Section Rendering: Use a helper method to check page access and hide/show sections:

  @if (await User.IsAuthorizedForPage("/Admin/Client"))
  {
      <div class="admin-controls">
          <!-- Admin-only content -->
      </div>
  }
  

2. Field-Level Permission (Per-Role/User Field Access) #

Backend Implementation #

• Field Permission Store: Create a FieldPermissions table with PermissionId, EntityName (e.g., "SalesReport"), FieldName, RoleName, UserId (for user-specific rules).
• Action Filter for Field Stripping: Implement an action filter that intercepts API responses and removes unauthorized fields:

  public class FieldAuthorizationFilter : ActionFilterAttribute
  {
      private readonly IPermissionService _permissionService;
  
      public FieldAuthorizationFilter(IPermissionService permissionService)
      {
          _permissionService = permissionService;
      }
  
      public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
      {
          var resultContext = await next();
          if (resultContext.Result is ObjectResult objectResult && objectResult.Value is SalesReport report)
          {
              var allowedFields = await _permissionService.GetAllowedFieldsAsync(context.HttpContext.User, "SalesReport");
              // Use reflection to remove restricted fields
              var reportType = typeof(SalesReport);
              foreach (var prop in reportType.GetProperties())
              {
                  if (!allowedFields.Contains(prop.Name))
                  {
                      prop.SetValue(report, null);
                  }
              }
          }
      }
  }
  

• Apply the Filter: Add it to relevant controllers or register as a global filter.

Frontend (Razor) Implementation #

• Fetch Allowed Fields: On page load, call an API endpoint to get the user’s allowed fields for the current entity.
• Conditional Column Rendering: Only render table columns if the field is in the allowed list:

  <table class="table">
      <thead>
          <tr>
              @if (Model.AllowedFields.Contains("TotalSales"))
              {
                  <th>Total Sales</th>
              }
              @if (Model.AllowedFields.Contains("CustomerEmail"))
              {
                  <th>Customer Email</th>
              }
          </tr>
      </thead>
      <tbody>
          @foreach (var item in Model.ReportData)
          {
              <tr>
                  @if (Model.AllowedFields.Contains("TotalSales"))
                  {
                      <td>@item.TotalSales</td>
                  }
                  @if (Model.AllowedFields.Contains("CustomerEmail"))
                  {
                      <td>@item.CustomerEmail</td>
                  }
              </tr>
          }
      </tbody>
  </table>
  

3. Row-Level Data Permission (Branch-Specific Access) #

Backend Implementation #

• Row Permission Store: Create a RowPermissions table with PermissionId, EntityName (e.g., "Customer"), UserId, RoleName, AllowedBranchIds.
• Profile Service for Claims Enhancement: Add allowed branch IDs as claims to the user’s IdentityServer4 token, so you can access them directly in queries:

  public class CustomProfileService : IProfileService
  {
      private readonly IPermissionService _permissionService;
  
      public CustomProfileService(IPermissionService permissionService)
      {
          _permissionService = permissionService;
      }
  
      public async Task GetProfileDataAsync(ProfileDataRequestContext context)
      {
          var allowedBranches = await _permissionService.GetAllowedBranchesAsync(context.Subject, "Customer");
          context.IssuedClaims.AddRange(allowedBranches.Select(b => new Claim("allowed_branch", b.ToString())));
      }
  
      public async Task IsActiveAsync(IsActiveContext context)
      {
          context.IsActive = true; // Implement your own logic here
      }
  }
  

• Register the Profile Service: In your IdentityServer4 setup:

  services.AddProfileService<CustomProfileService>();
  

• Filter Data in Repositories: Use the allowed_branch claims to filter data at the repository level:

  public async Task<List<Customer>> GetAllowedCustomersAsync(ClaimsPrincipal user)
  {
      var allowedBranchIds = user.Claims
          .Where(c => c.Type == "allowed_branch")
          .Select(c => int.Parse(c.Value))
          .ToList();
  
      return await _dbContext.Customers
          .Where(c => allowedBranchIds.Contains(c.BranchId))
          .ToListAsync();
  }
  

Frontend (Razor) Implementation #

• No Frontend Filtering: Row-level access is enforced strictly at the backend, so the frontend only displays the data returned by the API. If you need a branch selector, fetch the allowed branches from an endpoint and render only those options:

  <select asp-for="SelectedBranchId">
      @foreach (var branch in Model.AllowedBranches)
      {
          <option value="@branch.Id">@branch.Name</option>
      }
  </select>
  

Key Principles for No Hardcoding #

• Centralized Permission Store: All rules live in the database, so you can add/edit/remove permissions without changing code.
• Reusable Permission Service: Abstract all permission queries into an IPermissionService to keep your authorization logic clean and maintainable.
• Dynamic Claims & Policies: Avoid hardcoding role names or permission values—let the database drive all authorization decisions.

内容的提问来源于stack exchange，提问作者Payam Khaninejad