Authentication and RBAC

Relevant source files

The following files were used as context for generating this wiki page:

• src/controllers/graphql.rs
• examples/axum_example/api/src/lib.rs
• sea-orm-pro/src/config.rs
• config/development.yaml
• migration/src/m20250101_000002_seed_users.rs
• src/graphql/query_root.rs

The Authentication and Role-Based Access Control (RBAC) system in SeaORM Pro provides a secure framework for managing user access to the admin panel and its associated GraphQL API. The system utilizes JSON Web Tokens (JWT) for session management and supports configurable RBAC policies to restrict administrative actions.

The implementation spans across the core sea-orm-pro library, which defines configuration structures, and the application layer, which implements the request handling and authorization logic. In development and demo environments, the system includes pre-seeded users with varying roles to facilitate testing.

Sources: sea-orm-pro/src/config.rs:43-46, examples/axum_example/api/src/lib.rs:207-251, migration/src/m20250101_000002_seed_users.rs

Authentication Flow

Authentication is primarily handled via JWT. The application expects an Authorization header containing a Bearer token for protected routes, including GraphQL endpoints and the current user profile.

Login and Token Issuance

The login process validates user credentials (email and password) against the database. Upon success, the server returns a payload containing a JWT token, user persistent ID (PID), and verification status.

Request Validation

For every protected request, the server extracts the token from the Authorization header. In the Axum example implementation, this is checked by matching a known demo token or validating the JWT claims.

Step	Action	Logic
1	Extract Header	Retrieve AUTHORIZATION key from HeaderMap.
2	Token Check	Ensure header starts with Bearer and contains valid token.
3	Claim Extraction	Extract pid (User Email/ID) from JWT claims.
4	Database Verification	Filter User Entity by the extracted PID.

Sources: examples/axum_example/api/src/lib.rs:253-265, src/controllers/graphql.rs:30-38

Role-Based Access Control (RBAC)

RBAC is a configurable feature defined in the site configuration. It allows the system to toggle permissions-based logic globally.

RBAC Configuration

The configuration structure defines whether RBAC is enabled for the site. This is typically loaded from the config.toml file within the admin configuration directory.

#[derive(Debug, Default, Serialize, Deserialize)]
pub struct RbacCfg {
    /// Is RBAC enabled?
    pub enable: bool,
}

Sources: sea-orm-pro/src/config.rs:43-46

GraphQL Authorization and Read-Only Mode

The system implements a Readonly extension for the GraphQL schema, particularly useful for demo environments. This extension intercepts queries and prevents Mutation operations if a "DEMO_SITE" flag is active.

Security Configuration

The system's security parameters are defined in the application environment files (e.g., development.yaml). These settings govern the JWT lifecycle.

Parameter	Description	Source
auth.jwt.secret	The secret key used for signing and verifying tokens.	config/development.yaml:153
auth.jwt.expiration	Token lifespan in seconds (Default: 604,800 or 7 days).	config/development.yaml:155

Data Seeding and Users

The migration system seeds default users to establish an initial access control state. This includes different user identities like "Admin", "Manager", and "Public" to represent different tiers of access.

Email	Name	Default Purpose
admin@sea-ql.org	Admin	Full administrative access.
manager@sea-ql.org	Manager	Management level access.
public@sea-ql.org	Public	Limited/Restricted access.

Sources: migration/src/m20250101_000002_seed_users.rs:13-75

Conclusion

The Authentication and RBAC system in SeaORM Pro provides a robust foundation for securing the admin interface. By combining JWT-based authentication with a flexible configuration for RBAC and a dedicated Readonly mode for GraphQL, the system ensures that data access is restricted according to the environment and user identity. All security parameters are centralized in configuration files, allowing for easy adjustment of token expiration and secret keys.