Is your feature request related to a problem? Please describe.

I've noticed an opportunity to improve authentik's security posture and user experience. Currently, when no policy/group is selected for access control, the default behavior grants access to everyone. While functional, this "default-open" approach could be enhanced to better align with security best practices and user expectations, where typically "no selection = no access."

Describe the solution you'd like

Implement a "default-closed" behavior where no policy/group/filter selection results in denied access. To maintain flexibility, introduce an explicit "Allow All" policy that administrators can deliberately apply when open access is desired. This would make security intentions clearer while providing smooth migration for existing configurations.

Describe alternatives you've considered

I haven't found any alternatives that would provide the same level of security improvement and clarity. The proposed solution offers the best balance of enhanced security, explicit configuration, and backwards compatibility through automated migration.

Additional context

This pattern enhancement would benefit multiple areas of authentik (applications, SCIM providers, flows, stages) f.e. in PR #13947. The change would strengthen security defaults while making administrator intentions more explicit and auditable.

---

Streamline and Reevaluate Filter Behavior for Improved Security and UX

Summary

The current policy and filtering behavior in authentik has a potentially dangerous anti-pattern: when no policy or group is selected, access to all is granted. This behavior is counterintuitive, poses security risks, and can confuse new users who might assume that no selection means no access.

This issue proposes a fundamental change to this behavior across all filtering mechanisms in authentik, including policies, groups, and other access controls.

Current Behavior (Anti-Pattern)

Currently, throughout authentik:

• When no policies are bound to an application → all users have access
• When no groups are selected in filters → all groups are included
• When no specific restrictions are applied → everything is allowed

This "default-open" approach is evident in:

• Application access controls
• SCIM provider group filtering (as noted in PR providers/scim: modify user- and group syncing behavior #13947)
• Flow policy bindings
• Stage bindings
• Various other filtering mechanisms

Security and UX Concerns

1. Security Risk: Administrators might create an application thinking it's restricted, but if they haven't explicitly added policies/groups, it's accessible to everyone.

2. Confusion for New Users: The mental model most users have is that "no selection = no access", not "no selection = everyone has access".

3. Accidental Exposure: Easy to accidentally expose resources by forgetting to add restrictions rather than forgetting to add permissions.

4. Inconsistent with Security Best Practices: Goes against the principle of "default deny" commonly used in security-conscious systems.

Proposed Solution

1. Change Default Behavior

• New default: When no policy/group/filter is selected → access is denied
• This creates a "default-closed" security posture
• Aligns with user expectations and security best practices

2. Introduce "Allow All" Policy

Use an Expression Policy that returns True to explicitly grant access to everyone when needed:

• Makes the intent clear and deliberate
• Provides an easy migration path for existing setups
• Uses existing policy infrastructure

3. UI/UX Improvements

Update UI elements to support this new behavior:

• Update evaluation logic to deny access when no selections are made
• Add explicit "Allow All" checkbox/option where applicable

4. Migration Strategy

• Automatically apply the new "Allow All" policy to existing configurations where no selection currently exists
• Set a flag during migration to identify auto-migrated configurations

Implementation Areas

UI Components to Update

1. Application Policy/Group/User Bindings

   • /web/src/admin/applications/ApplicationForm.ts
   • /web/src/admin/policies/BoundPoliciesList.ts
   • Update evaluation behavior when no bindings exist

2. SCIM Provider Forms

   • /web/src/admin/providers/scim/SCIMProviderForm.ts
   • Update group filters UI to reflect new behavior
   • Add "Sync All Groups" checkbox as explicit option

Documentation Updates

1. Core Concepts

   • Update /website/docs/policies/index.md to explain new default behavior

2. Application Management

   • Update /website/docs/applications/manage_apps.md
   • Change text from "When nothing is bound, everyone has access" to new behavior

3. Policy Documentation

   • Update /website/docs/policies/working_with_policies.md
   • Add section on "Allow All" policy
   • Explain migration and security benefits

4. SCIM Provider Docs

   • Update /website/docs/providers/scim/index.md
   • Document new group filtering behavior

5. Migration Guide

   • Create /website/docs/releases/202X.X.md migration section
   • Provide clear upgrade instructions

API Changes

1. Add new "Allow All" policy type to the policy engine
2. Update serializers to handle the new default behavior
3. Ensure backwards compatibility through migration

Benefits

1. Improved Security: Default-deny posture prevents accidental exposure
2. Better UX: Aligns with user mental models and expectations
3. Clearer Intent: Explicit "Allow All" makes administrator intentions obvious
4. Easier Auditing: Can easily identify intentionally open resources
5. Reduced Mistakes: Harder to accidentally leave resources unprotected

Backwards Compatibility

The migration process should:

1. Create a system-policy "Allow All" which always returns True
2. Detect all instances where no selection previously meant "allow all"
3. Bind instances to the "Allow All" Expression Policy

Related Issues and PRs

• PR providers/scim: modify user- and group syncing behavior #13947 - Modifies SCIM provider user and group syncing behavior
• Issue SCIM Group Filtering #6065 - SCIM Group Filtering request

Implementation Priority

Given the security implications, this should be considered for the next major release with:

1. Clear communication in release notes
2. Prominent migration documentation

This change would significantly improve authentik's security posture while making the system more intuitive for administrators.