Struct AccessPolicy 

pub struct AccessPolicy<R, G>
where
    R: AccessHierarchy + Eq + Display,
    G: Eq,
{ /* private fields */ }

Domain object representing access requirements for a protected resource.

This captures the business rules about what roles, groups, or permissions are required to access a particular resource or route. Access is granted if the user meets ANY of the specified requirements (OR logic).

Implementations

impl<R, G> AccessPolicy<R, G>

where R: AccessHierarchy + Eq + Display, G: Eq,

pub fn deny_all() -> Self

Creates a new access policy with no requirements (denies all access).

This is the secure default - no access is granted unless explicitly configured through the builder methods.

pub fn require_role(role: R) -> Self

Creates a policy that allows access for users with the specified role.

Use this when you need exact role matching without hierarchy. For scenarios where supervisor roles should also have access, use require_role_or_supervisor().

Example

use axum_gate::authz::AccessPolicy;
use axum_gate::prelude::{Role, Group};

let policy: AccessPolicy<Role, Group> = AccessPolicy::require_role(Role::Admin);

pub fn require_role_or_supervisor(role: R) -> Self

Creates a policy that allows access for users with the specified role or any supervisor role.

Use this when you want hierarchical access control where higher-level roles automatically inherit permissions from lower-level roles. This is ideal for organizational structures where managers should have access to employee resources.

This leverages the role hierarchy defined by the AccessHierarchy trait.

Example

use axum_gate::authz::AccessPolicy;
use axum_gate::prelude::{Role, Group};

// Allows Moderator role and Admin role (if Admin supervises Moderator)
let policy: AccessPolicy<Role, Group> = AccessPolicy::require_role_or_supervisor(Role::Moderator);

pub fn require_group(group: G) -> Self

Creates a policy that allows access for users in the specified group.

Use this for team-based or department-based access control. Groups are ideal for cross-cutting concerns that don’t fit hierarchical role structures, such as project teams, geographical regions, or temporary access grants.

Example

use axum_gate::authz::AccessPolicy;
use axum_gate::prelude::{Role, Group};

let policy = AccessPolicy::<Role, Group>::require_group(Group::new("engineering"));

pub fn require_permission<P: Into<PermissionId>>(permission: P) -> Self

Creates a policy that allows access for users with the specified permission.

Example

use axum_gate::authz::AccessPolicy;
use axum_gate::permissions::PermissionId;
use axum_gate::prelude::{Role, Group};

// Using a permission name (hashed deterministically to 64-bit ID)
let policy: AccessPolicy<Role, Group> =
    AccessPolicy::require_permission(PermissionId::from("read:api"));

// Or directly from &str via Into<PermissionId>
let policy2: AccessPolicy<Role, Group> =
    AccessPolicy::require_permission("write:api");

pub fn or_require_role(self, role: R) -> Self

Adds an additional role requirement to this policy.

Access will be granted if the user has ANY of the configured roles.

pub fn or_require_role_or_supervisor(self, role: R) -> Self

Adds an additional role or supervisor requirement to this policy.

Access will be granted if the user has the specified role or supervises it.

pub fn or_require_group(self, group: G) -> Self

Adds an additional group requirement to this policy.

Access will be granted if the user is in ANY of the configured groups.

pub fn or_require_permission<P: Into<PermissionId>>(self, permission: P) -> Self

Adds an additional permission requirement to this policy.

Access will be granted if the user has ANY of the configured permissions.

pub fn or_require_permissions<P: Into<PermissionId>>( self, permissions: Vec<P>, ) -> Self

Adds multiple additional permission requirements to this policy.

Access will be granted if the user has ANY of the configured permissions.

pub fn role_requirements(&self) -> &[AccessScope<R>]

Returns the role requirements for this policy.

pub fn group_requirements(&self) -> &[G]

Returns the group requirements for this policy.

pub fn permission_requirements(&self) -> &Permissions

Returns the permission requirements for this policy.

pub fn denies_all(&self) -> bool

Returns true if this policy has no requirements (denies all access).

This is useful for validation - a policy that denies all access might indicate a configuration error.

pub fn has_requirements(&self) -> bool

Returns true if this policy has at least one requirement configured.

This is useful for validating that a policy is properly configured with some access requirements rather than being completely empty.

pub fn into_components(self) -> (Vec<AccessScope<R>>, Vec<G>, Permissions)

Converts this policy into the components needed by the authorization service.

This is primarily used internally when bridging to the authorization service.

Trait Implementations

impl<R, G> Clone for AccessPolicy<R, G>

where R: AccessHierarchy + Eq + Display + Clone, G: Eq + Clone,

fn clone(&self) -> AccessPolicy<R, G>

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<R, G> Debug for AccessPolicy<R, G>

where R: AccessHierarchy + Eq + Display + Debug, G: Eq + Debug,

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.