Conditional Access – Part 1

/ Conditional Access, Identity Server

đź’ˇEnhancing Security with Conditional Access Policies in IdentityServer

Securing access to resources is more critical than ever. As organizations increasingly adopt cloud services and mobile workforces, the need for robust, adaptable security measures has never been greater. Conditional Access Policies (CAPs) have emerged as a powerful tool to enforce specific conditions under which users can access resources, thereby enhancing overall security posture.

At the heart of Conditional Access lies the ability to apply dynamic, context-aware rules that go beyond traditional static access controls. These policies consider various signals such as user identity, device health, location, and more to determine whether access should be granted or denied. By leveraging Conditional Access, organizations can ensure that only the right users, under the right conditions, can access sensitive data and applications.

One effective way to implement Conditional Access is by utilizing the capabilities provided by IdentityServer, a flexible and powerful framework for handling authentication and authorization in .NET applications. Specifically, the ICustomAuthorizeRequestValidator interface in IdentityServer allows developers to implement custom validation logic for authorization requests, providing an additional layer of security tailored to specific business needs.

🛠️Implementing Simple Conditional Access with IdentityServer

Imagine a scenario where an organization wants to ensure that users can only access certain clients if they possess specific claims. This requirement can be seamlessly enforced using the ICustomAuthorizeRequestValidator interface. By checking for the presence of required claims during the authorization process, we can block or refuse authorization requests that do not meet the predefined conditions. This approach not only strengthens security but also ensures compliance with organizational policies.

Here’s an example validator that performs such a task;
You can see it implemented in code here in my GitHub sample

public class CustomAuthorizeEndpointValidator(IProfileService profileService) : ICustomAuthorizeRequestValidator
{
    private readonly IProfileService _profileService = profileService;

    public Task ValidateAsync(CustomAuthorizeRequestValidationContext context)
    {
        Log.Information(messageTemplate: "Starting custom Authorize Endpoint validation");

        var validatedRequest = context.Result.ValidatedRequest;
        var claimsPrincipal = validatedRequest.Subject;

        // Only want to trigger this once the user is authenticated.
        if (!claimsPrincipal.IsAuthenticated())
            return Task.CompletedTask;

        // Setup the profile data request.
        var dataRequest = new ProfileDataRequestContext
        {
            ValidatedRequest = validatedRequest,
            Subject = claimsPrincipal,
            Client = validatedRequest.Client,

            // We're only interested in the role claim at this point.
            RequestedClaimTypes = [JwtClaimTypes.Role]
        };

        // Execute the request and determine if the user has the required role for the client.
        _profileService.GetProfileDataAsync(dataRequest);

        bool hasRequiredClaim = dataRequest.IssuedClaims
            .Any(claim =>
                JwtClaimTypes.Role.Equals(claim.Type) &&
                (validatedRequest.ClientId + "_BasicAccess").Equals(claim.Value)
            );

        // If the required role wasn't found, we raise an error.
        if (!hasRequiredClaim)
        {
            context.Result.IsError = true;
            context.Result.Error = "missing_basic_access";
            context.Result.ErrorDescription = "User doesn't have permission to access the specified client.";

            Log.Warning(messageTemplate: "Authorization rejected because of missing application permissions");
        }

        return Task.CompletedTask;
    }
}

🤔When Should the Identity Provider Perform the Check?

  • Centralized Control: The Identity Provider (IdP) is often the central authority for authentication and authorization decisions. Placing conditional access logic in the IdP ensures that these policies are enforced consistently across all clients and applications.
  • Security: By handling the check at the IdP level, you reduce the risk of inconsistent implementations across different clients. It ensures that security policies are enforced uniformly and not bypassed.
  • Simplicity for Clients: Clients can be simpler because they do not need to implement complex authorization logic. They can rely on the IdP to handle all necessary checks and only process requests that have already been authorized.

🤔When Should the Client Perform the Check?

  • Client-Specific Logic: If the conditional access logic is highly specific to certain clients or if different clients have very different requirements, it might make sense to implement the check at the client level.
  • Performance Considerations: In some cases, it might be more efficient for the client to perform certain checks, especially if those checks involve client-specific context that the IdP does not have.
  • Layered Security: Implementing checks both at the IdP and client level can provide layered security. The IdP can enforce general policies, while the client can enforce more specific ones.

🔬Best Current Practice

  1. Centralize Common Policies: For common conditional access policies that apply across multiple clients, it’s best to implement these checks at the IdP level using ICustomAuthorizeRequestValidator or similar mechanisms.
  2. Client-Specific Policies: For client-specific policies that cannot be generalized, the client may need to implement additional checks.
  3. Layered Approach: Consider a layered approach where the IdP enforces baseline security policies, and clients enforce additional specific policies. This provides robust security while allowing for flexibility.

Using ICustomAuthorizeRequestValidator for conditional access checks at the Identity Provider level is appropriate and aligns with best practices for centralized control and security. It ensures consistent enforcement of policies and simplifies client implementations. However, depending on specific use cases, additional checks at the client level may be necessary, creating a multi-tiered security approach.

Scroll to Top