ferrox-py-auth 1.0.0__tar.gz

ferrox_py_auth-1.0.0/PKG-INFO

@@ -0,0 +1,51 @@
+Metadata-Version: 2.5
+Name: ferrox-py-auth
+Version: 1.0.0
+Summary: IAM, SSO, GDPR and RBAC suite for Ferrox ecosystem.
+Author: AI-Autistic-Intelligence
+Requires-Python: >=3.11
+Requires-Dist: ferrox-py>=1.0.0
+Requires-Dist: pydantic>=2.0
+Description-Content-Type: text/markdown
+
+# Ferrox-Py-Auth
+
+## 1. Overview (What does this do?)
+The `ferrox-py-auth` module is a specialized extension for the Ferrox ecosystem that provides a comprehensive Identity & Access Management (IAM) suite. It delivers pre-built functionalities for managing user registrations, Single Sign-On (SSO), Role-Based Access Control (RBAC), and compliance with European data privacy laws (GDPR).
+
+## 2. Philosophy (Why does it exist?)
+Authentication and authorization are complex and highly sensitive domains. Re-implementing secure login flows, password hashing, SSO integration, and GDPR-compliant data deletion mechanisms for every new project is not only inefficient but heavily prone to critical security vulnerabilities. This module exists to provide a battle-tested, standardized "plug-and-play" identity solution that adheres to strict zero-trust principles.
+
+## 3. Target Audience (Who is it for?)
+This module is intended for backend engineers and security architects building Enterprise SaaS, financial platforms, or any consumer-facing application where data privacy (like GDPR compliance) and secure access controls are legal or operational requirements.
+
+## 4. Architecture (How does it work?)
+`ferrox-py-auth` plugs directly into the **7-Layer Onion Request Pipeline** of the core `ferrox-py` framework, specifically occupying Layers 3 (Threat Engine) and 4 (Auth Guards). It registers a set of domain Services (`AuthService`, `GdprService`) into the central IoC Container and exposes abstract Data Models (`User`, `UserIdentity`) that can be persisted via MongoDB or SQLAlchemy adapters provided by the `ferrox-py` Data Component.
+
+## 5. Installation / Setup
+This package requires the core `ferrox-py` framework to function. Install it via pip:
+
+```bash
+pip install ferrox-py-auth
+```
+Ensure you have configured a persistent database layer (either SQL or NoSQL) in your core application to store the user identities.
+
+## 6. Quickstart (Usage)
+```python
+from ferrox_py.core.app import FerroxApp
+from ferrox_py.core.container import Container
+from ferrox_py_auth import AuthModule
+
+# Initialize the IoC container
+container = Container()
+
+# The AuthModule automatically registers the AuthService, GdprService, 
+# and Auth Guards into the container and application lifecycle.
+container.register_module(AuthModule)
+
+app = FerroxApp(container)
+app.start()
+```
+
+## 7. Ecosystem Integration
+This module relies heavily on the **Security** component of the core `ferrox-py` framework for generating and parsing PASETO/JWT tokens. It also serves as a foundational dependency for `ferrox-py-commerce`, as a validated User context is required before initiating billing or subscription processes.

ferrox_py_auth-1.0.0/README.md

@@ -0,0 +1,41 @@
+# Ferrox-Py-Auth
+
+## 1. Overview (What does this do?)
+The `ferrox-py-auth` module is a specialized extension for the Ferrox ecosystem that provides a comprehensive Identity & Access Management (IAM) suite. It delivers pre-built functionalities for managing user registrations, Single Sign-On (SSO), Role-Based Access Control (RBAC), and compliance with European data privacy laws (GDPR).
+
+## 2. Philosophy (Why does it exist?)
+Authentication and authorization are complex and highly sensitive domains. Re-implementing secure login flows, password hashing, SSO integration, and GDPR-compliant data deletion mechanisms for every new project is not only inefficient but heavily prone to critical security vulnerabilities. This module exists to provide a battle-tested, standardized "plug-and-play" identity solution that adheres to strict zero-trust principles.
+
+## 3. Target Audience (Who is it for?)
+This module is intended for backend engineers and security architects building Enterprise SaaS, financial platforms, or any consumer-facing application where data privacy (like GDPR compliance) and secure access controls are legal or operational requirements.
+
+## 4. Architecture (How does it work?)
+`ferrox-py-auth` plugs directly into the **7-Layer Onion Request Pipeline** of the core `ferrox-py` framework, specifically occupying Layers 3 (Threat Engine) and 4 (Auth Guards). It registers a set of domain Services (`AuthService`, `GdprService`) into the central IoC Container and exposes abstract Data Models (`User`, `UserIdentity`) that can be persisted via MongoDB or SQLAlchemy adapters provided by the `ferrox-py` Data Component.
+
+## 5. Installation / Setup
+This package requires the core `ferrox-py` framework to function. Install it via pip:
+
+```bash
+pip install ferrox-py-auth
+```
+Ensure you have configured a persistent database layer (either SQL or NoSQL) in your core application to store the user identities.
+
+## 6. Quickstart (Usage)
+```python
+from ferrox_py.core.app import FerroxApp
+from ferrox_py.core.container import Container
+from ferrox_py_auth import AuthModule
+
+# Initialize the IoC container
+container = Container()
+
+# The AuthModule automatically registers the AuthService, GdprService, 
+# and Auth Guards into the container and application lifecycle.
+container.register_module(AuthModule)
+
+app = FerroxApp(container)
+app.start()
+```
+
+## 7. Ecosystem Integration
+This module relies heavily on the **Security** component of the core `ferrox-py` framework for generating and parsing PASETO/JWT tokens. It also serves as a foundational dependency for `ferrox-py-commerce`, as a validated User context is required before initiating billing or subscription processes.

ferrox_py_auth-1.0.0/docs/auth_service.md

@@ -0,0 +1,35 @@
+# AuthService (Authentication & SSO)
+
+## 1. Overview (What does this do?)
+The `AuthService` is a singleton service registered within the Ferrox IoC container that handles all aspects of user registration, login, and identity verification. It provides out-of-the-box support for traditional email/password flows as well as external Single Sign-On (SSO) integrations.
+
+## 2. Philosophy (Why does it exist?)
+Modern web applications rarely rely solely on basic username/password authentication anymore. Users expect seamless logins via Google, Apple, or GitHub. The `AuthService` exists to abstract the complexities of linking multiple external identities to a single user account and to enforce secure registration flows (like Double Opt-In) by default.
+
+## 3. Target Audience (Who is it for?)
+This service is for backend developers who need to implement a secure user registration and login system without dealing with the low-level mechanics of hashing passwords, generating secure tokens, or verifying OAuth2 payloads manually.
+
+## 4. Architecture (How does it work?)
+- **Standard Registration**: Handles traditional credentials. It automatically initiates a "Double Opt-In" process, meaning the account remains in a locked, unverified state until a confirmation email link is clicked.
+- **SSO Integration (OIDC/OAuth2)**: Handles login/registration via external Identity Providers (IdPs). The identity (e.g., a Google ID) is saved inside an `identities` sub-document associated with the user. If a user registers via SSO, the "email verified" status is automatically inherited from the trusted IdP, bypassing the email opt-in step.
+
+## 5. Installation / Setup
+The `AuthService` is automatically registered in your IoC container when you import and register the `AuthModule` from `ferrox-py-auth`. You may need to configure external OAuth2 credentials (Client IDs and Secrets) in your environment variables for SSO functionality.
+
+## 6. Quickstart (Usage)
+```python
+from ferrox_py_auth.services.auth_service import AuthService
+
+# Example: Resolving the service from the container and registering via SSO
+async def handle_google_callback(auth_service: AuthService, google_payload: dict):
+    # Registration via SSO (Bypasses Email Validation automatically)
+    user = await auth_service.register_via_sso(
+        email=google_payload["email"],
+        provider="google",
+        provider_id=google_payload["sub"]
+    )
+    return user
+```
+
+## 7. Ecosystem Integration
+The `AuthService` leverages the core **Data Component** to persist the `User` models to the database. Upon successful login, it interacts with the **Security Component** to generate a secure PASETO or JWT token, which is then returned to the client to be used in the Authorization header of subsequent requests.

ferrox_py_auth-1.0.0/docs/gdpr_service.md

@@ -0,0 +1,36 @@
+# GdprService
+
+## 1. Overview (What does this do?)
+The `GdprService` is a specialized service that abstracts complex commands required to comply with modern privacy laws (like the GDPR in Europe and the CCPA in California). It provides automated mechanisms for data portability (exporting user data) and the Right to be Forgotten (deleting or anonymizing user data).
+
+## 2. Philosophy (Why does it exist?)
+Compliance with data privacy laws is a strict legal requirement, not a feature. Leaving developers to manually write cascade deletions for user data is highly dangerous; it often results in orphaned records, corrupted relational constraints, or, worse, incomplete deletions that violate privacy laws. This service exists to centralize and automate secure data anonymization and extraction.
+
+## 3. Target Audience (Who is it for?)
+This service is essential for Data Protection Officers (DPOs), compliance engineers, and backend developers who are legally required to provide users with the ability to download their data or permanently delete their accounts from the SaaS platform.
+
+## 4. Architecture (How does it work?)
+- **Right to be Forgotten (Deletion)**: The `delete_user_data` method securely masks, anonymizes, or hard-deletes Personally Identifiable Information (PII) across the database. It triggers an internal event that other modules can listen to, ensuring data is scrubbed across all bounded contexts.
+- **Data Portability**: The `export_user_data` method aggregates the entire user state and preferences into a readable JSON or CSV format, ready to be compressed into a `.zip` file and delivered to the user.
+
+## 5. Installation / Setup
+The `GdprService` is available out of the box when using `ferrox-py-auth`. No additional installation is required, but you must ensure your specific data repositories implement the required anonymization hooks if you have custom tables containing PII.
+
+## 6. Quickstart (Usage)
+```python
+from ferrox_py_auth.services.gdpr_service import GdprService
+
+async def handle_account_deletion(gdpr_service: GdprService, user_id: str):
+    # Perform a compliant soft delete or hard delete of PII
+    await gdpr_service.delete_user_data(user_id=user_id)
+    return {"message": "Account successfully anonymized."}
+
+async def handle_data_export(gdpr_service: GdprService, user_id: str):
+    # Generate a full export of the user's data footprint
+    dump = await gdpr_service.export_user_data(user_id=user_id)
+    # Returns a comprehensive dict: { "email": "...", "identities": [...], "created_at": "..." }
+    return dump
+```
+
+## 7. Ecosystem Integration
+The `GdprService` integrates with the **CQRS and Event Dispatcher** from the core framework. When `delete_user_data` is called, it emits a `UserDeletedEvent`. Other modules (like `ferrox-py-commerce`) subscribe to this event to safely cancel active subscriptions and anonymize billing records without creating tightly coupled dependencies.

ferrox_py_auth-1.0.0/docs/models.md

@@ -0,0 +1,44 @@
+# Models (Pydantic / Mongo)
+
+## 1. Overview (What does this do?)
+The Models module exports the base Data Transfer Objects (DTOs) and Database Schemas used to represent Users and their authentication states. These models are statically validated using Pydantic and are designed to be natively serialized/deserialized into MongoDB or adapted for SQLAlchemy ORMs.
+
+## 2. Philosophy (Why does it exist?)
+A fragmented definition of what constitutes a "User" leads to bugs across different microservices. By providing strict, centrally defined Pydantic models for `User` and `UserIdentity`, `ferrox-py-auth` ensures that every part of the application agrees on the structure of the identity data, ensuring data integrity and fast validation at the API boundaries.
+
+## 3. Target Audience (Who is it for?)
+This module is for developers integrating the Auth module who need to understand the underlying data structure of the User object, or those who need to extend the base models with custom application-specific fields (like `company_name` or `avatar_url`).
+
+## 4. Architecture (How does it work?)
+- **UserIdentity**: A sub-document representing an external Identity Provider (IdP) link. It stores the `provider` (e.g., "google", "apple", "facebook", "local"), the `provider_id` (the alphanumeric unique identifier from the IdP), and auditing timestamps like `last_login`.
+- **User**: The primary aggregate root model. It contains the main `email` address, manages critical boolean flags (`is_email_verified`, `is_active`, `is_locked`), holds a list of `UserIdentity` objects, and contains an array of `roles` (strings) used by the RBAC engine.
+
+## 5. Installation / Setup
+These models require `pydantic` (installed by default with the core framework). If you intend to use them directly with a NoSQL database, the `motor` driver from the core Data Component is recommended.
+
+## 6. Quickstart (Usage)
+```python
+from ferrox_py_auth.models.user import User, UserIdentity
+from datetime import datetime
+
+# Creating an instance of a User manually (usually handled by AuthService)
+identity = UserIdentity(
+    provider="google",
+    provider_id="sub_123456789",
+    last_login=datetime.utcnow()
+)
+
+new_user = User(
+    email="test@example.com",
+    is_email_verified=True,
+    is_active=True,
+    roles=["user", "editor"],
+    identities=[identity]
+)
+
+# The model will automatically validate its schema upon instantiation
+print(new_user.model_dump_json())
+```
+
+## 7. Ecosystem Integration
+These models are utilized by the **Validation Pipes** (Layer 5) to validate incoming request bodies containing user data. They are also intrinsically linked to the **Data Component**, where they act as the primary interface between the `AuthService` and the database repository.

ferrox_py_auth-1.0.0/docs/overview.md

@@ -0,0 +1,39 @@
+# Ferrox-Py-Auth Overview
+
+## 1. Overview (What does this do?)
+The `ferrox-py-auth` package provides a unified, enterprise-ready Identity, Access Management (IAM), and Data Privacy (GDPR) solution designed specifically to plug into the core `ferrox-py` framework. 
+
+## 2. Philosophy (Why does it exist?)
+In complex distributed systems and modern SaaS architectures, authentication is rarely as simple as a single "Users" SQL table. It requires dynamic extension to support Single Sign-On (Google, Apple, Microsoft), Multi-Factor Authentication, and a decoupled data architecture to scale securely. This package exists to encapsulate all that complexity into a secure, reusable module so developers can focus on business logic rather than writing boilerplate auth code.
+
+## 3. Target Audience (Who is it for?)
+This package is built for application architects and backend engineers tasked with building secure platforms that require strict user identity tracking, varied permission levels (RBAC), and legal compliance with international privacy laws.
+
+## 4. Architecture (How does it work?)
+The Auth package seamlessly hooks into Layer 3 (Threat Engine) and Layer 4 (Auth Guards) of the `ferrox-py` Onion Request Pipeline. It provides the practical implementation for parsing tokens, validating user state, and persisting user data.
+Integrated features include:
+- Management of multiple users with SSO identities linked to the same aggregate entity.
+- Granular Role-Based Access Control (RBAC).
+- Ready-to-use GDPR tools (Right to be Forgotten, Data Portability).
+
+## 5. Installation / Setup
+Install the package alongside the core framework:
+```bash
+pip install ferrox-py-auth
+```
+Ensure that cryptographic keys used for token generation (JWT/PASETO) are injected securely via environment variables.
+
+## 6. Quickstart (Usage)
+To enable IAM across your application, register the module in your root configuration:
+
+```python
+from ferrox_py.core.container import Container
+from ferrox_py_auth import AuthModule
+
+container = Container()
+container.register_module(AuthModule)
+# Authentication and RBAC layers are now active globally.
+```
+
+## 7. Ecosystem Integration
+The Auth module is a fundamental prerequisite for many other ecosystem packages. For instance, `ferrox-py-commerce` requires a guaranteed, authenticated `User` context to bind payment methods and track subscription ownership securely.

ferrox_py_auth-1.0.0/docs/rbac.md

@@ -0,0 +1,32 @@
+# RBAC (Role-Based Access Control)
+
+## 1. Overview (What does this do?)
+The RBAC (Role-Based Access Control) module provides a granular mechanism for restricting access to specific API endpoints or Service methods based on the permissions assigned to the currently authenticated user. It exposes the `@require_roles` decorator for declarative access control.
+
+## 2. Philosophy (Why does it exist?)
+Hardcoding `if user.role == "admin"` statements inside controller logic leads to scattered, unmaintainable, and highly insecure code. The philosophy of this component is to extract access control entirely out of the business logic and enforce it at the pipeline boundary. If a user does not have the required role, the request is terminated before the domain logic is ever invoked.
+
+## 3. Target Audience (Who is it for?)
+This module is for developers building multi-tenant SaaS applications, administrative dashboards, or any system where different users (e.g., standard users, editors, superadmins) require different levels of access to the system resources.
+
+## 4. Architecture (How does it work?)
+When an HTTP or gRPC endpoint is called, the authorization token (JWT or PASETO) is validated at Layer 3 of the Onion Pipeline. The token payload contains the user's "claims", which include their list of `roles`. The `@require_roles` decorator operates at Layer 4. It intercepts the call *before* executing the controller, checks the local context for the extracted roles, and compares them against the required roles defined in the decorator.
+
+## 5. Installation / Setup
+RBAC functionalities are automatically available when you install `ferrox-py-auth`. No additional database setup is required for basic RBAC, as the roles are inherently expected to be embedded directly within the cryptographic token payload.
+
+## 6. Quickstart (Usage)
+```python
+from ferrox_py_auth.security.rbac import require_roles
+
+class AdminController:
+    
+    # Restrict this endpoint to users who have at least one of these roles
+    @require_roles("superadmin", "editor")
+    async def delete_article(self, request, article_id: str):
+        # Execution only reaches this point if the token contains a matching role
+        return {"status": "Article deleted successfully"}
+```
+
+## 7. Ecosystem Integration
+The RBAC decorator is tightly integrated with the core **Web & Transports Component**. By operating entirely on the Request context generated by the **Security Component**'s Auth Guards, it remains agnostic to the underlying web framework (e.g., FastAPI), allowing it to secure both HTTP REST endpoints and WebSocket connections uniformly.

ferrox_py_auth-1.0.0/ferrox_py_auth/__init__.py

@@ -0,0 +1 @@
+# init

ferrox_py_auth-1.0.0/ferrox_py_auth/controllers/auth_controller.py

@@ -0,0 +1,52 @@
+from fastapi import Request
+from pydantic import BaseModel
+from ferrox_py.core.controllers import BaseController
+from ferrox_py.core.container import Container
+from ..services.auth_service import AuthService
+from ..services.gdpr_service import GdprService
+from ..security.rbac import require_roles
+
+class LoginPayload(BaseModel):
+    email: str
+    password_hash: str
+
+class SsoPayload(BaseModel):
+    provider: str
+    provider_id: str
+    email: str
+
+class AuthController(BaseController):
+    def __init__(self, container: Container):
+        super().__init__(prefix="/auth", tags=["Auth & IAM"])
+        
+        self.auth = AuthService(container.resolve("JwtService"))
+        self.gdpr = GdprService(self.auth)
+        
+        @self.router.get("/config")
+        async def get_config():
+            return self.ok(self.auth.get_config(), "Auth settings retrieved")
+            
+        @self.router.post("/register")
+        async def register(payload: LoginPayload):
+            user = await self.auth.register_local(payload.email, payload.password_hash)
+            return self.created(user.model_dump(), "User registered. Please check your email.")
+            
+        @self.router.post("/sso")
+        async def sso_login(payload: SsoPayload):
+            token = await self.auth.login_sso(payload.provider, payload.provider_id, payload.email)
+            return self.ok({"token": token}, "SSO Login successful")
+            
+        @self.router.get("/gdpr/export")
+        @require_roles("user", "admin")
+        async def export_my_data(request: Request):
+            # Extract user_id from the authenticated request state
+            user_id = request.state.user["sub"]
+            data = await self.gdpr.export_data(user_id)
+            return self.ok(data, "GDPR Export ready")
+            
+        @self.router.delete("/gdpr/forget")
+        @require_roles("user", "admin")
+        async def delete_my_account(request: Request):
+            user_id = request.state.user["sub"]
+            success = await self.gdpr.forget_me(user_id)
+            return self.ok({"deleted": success}, "Account permanently deleted")

ferrox_py_auth-1.0.0/ferrox_py_auth/models/user.py

@@ -0,0 +1,16 @@
+from pydantic import BaseModel, Field
+from typing import List, Optional
+from datetime import datetime
+
+class Identity(BaseModel):
+    provider: str  # e.g., 'local', 'google', 'facebook', 'apple'
+    provider_id: str  # ID from the external provider or hash of password
+    created_at: datetime = Field(default_factory=datetime.utcnow)
+
+class User(BaseModel):
+    id: str
+    email: str
+    email_verified: bool = False
+    roles: List[str] = ["user"]
+    identities: List[Identity] = []
+    created_at: datetime = Field(default_factory=datetime.utcnow)

ferrox_py_auth-1.0.0/ferrox_py_auth/security/rbac.py

@@ -0,0 +1,26 @@
+from functools import wraps
+from typing import List
+from fastapi import Request
+from ferrox_py.core.errors import FerroxError
+
+def require_roles(*roles: str):
+    """
+    RBAC Decorator.
+    Extracts the user 'roles' claim from the JWT (attached to request.state.user)
+    and validates it against the required roles.
+    """
+    def decorator(func):
+        @wraps(func)
+        async def wrapper(request: Request, *args, **kwargs):
+            user_data = getattr(request.state, "user", None)
+            if not user_data:
+                raise FerroxError("Unauthorized - No JWT token found", 401)
+                
+            user_roles = user_data.get("roles", [])
+            
+            if not any(role in user_roles for role in roles):
+                raise FerroxError(f"Forbidden - Requires one of roles: {roles}", 403)
+                
+            return await func(request, *args, **kwargs)
+        return wrapper
+    return decorator

ferrox_py_auth-1.0.0/ferrox_py_auth/services/auth_service.py

@@ -0,0 +1,52 @@
+from ferrox_py.core.provider import injectable
+from ferrox_py.core.errors import FerroxError
+from ferrox_py.security.jwt import JwtService
+from ..models.user import User, Identity
+from typing import Dict, Any
+
+@injectable()
+class AuthService:
+    def __init__(self, jwt_service: JwtService):
+        self.jwt = jwt_service
+        self.enforce_sso_only = False  # Feature flag configurable by the application
+        
+        # Mock DB
+        self._users_db: Dict[str, User] = {}
+
+    def get_config(self) -> dict:
+        """Returns auth settings for the frontend (e.g. to hide password fields)."""
+        return {"enforce_sso_only": self.enforce_sso_only}
+
+    async def register_local(self, email: str, password_hash: str) -> User:
+        if self.enforce_sso_only:
+            raise FerroxError("Local registration is disabled by SSO policy", 403)
+            
+        if email in self._users_db:
+            raise FerroxError("Email already in use", 400)
+            
+        user = User(
+            id=email, 
+            email=email, 
+            identities=[Identity(provider="local", provider_id=password_hash)]
+        )
+        self._users_db[email] = user
+        
+        # Here we would trigger the MailerService for email_verified=True
+        print(f"AuthService: Emitting Email Confirmation for {email}")
+        return user
+
+    async def login_sso(self, provider: str, provider_id: str, email: str) -> str:
+        """Handles SSO login or account linkage if user already exists."""
+        user = self._users_db.get(email)
+        
+        if not user:
+            # Create new user, auto-verify email since it comes from trusted SSO
+            user = User(id=email, email=email, email_verified=True, identities=[])
+            self._users_db[email] = user
+            
+        # Link identity if not present
+        if not any(i.provider == provider for i in user.identities):
+            user.identities.append(Identity(provider=provider, provider_id=provider_id))
+            
+        # Issue JWT
+        return self.jwt.sign({"sub": user.id, "roles": user.roles})

ferrox_py_auth-1.0.0/ferrox_py_auth/services/gdpr_service.py

@@ -0,0 +1,31 @@
+from ferrox_py.core.provider import injectable
+from ferrox_py.core.errors import FerroxError
+from .auth_service import AuthService
+from typing import Dict
+
+@injectable()
+class GdprService:
+    def __init__(self, auth_service: AuthService):
+        self.auth = auth_service
+
+    async def export_data(self, user_id: str) -> Dict:
+        """Returns all PII (Personally Identifiable Information) for GDPR export."""
+        user = self.auth._users_db.get(user_id)
+        if not user:
+            raise FerroxError("User not found", 404)
+            
+        return {
+            "account": user.model_dump(),
+            "consent_logs": [],
+            "activity_logs": []
+        }
+
+    async def forget_me(self, user_id: str) -> bool:
+        """Right to be forgotten: Hard deletes the user and all associated identities."""
+        if user_id in self.auth._users_db:
+            del self.auth._users_db[user_id]
+            # In a real scenario, this would emit an event to soft-delete or anonymize 
+            # related records across the entire microservice ecosystem.
+            print(f"GdprService: User {user_id} completely deleted from system.")
+            return True
+        return False

ferrox_py_auth-1.0.0/pyproject.toml

@@ -0,0 +1,15 @@
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project]
+name = "ferrox-py-auth"
+version = "1.0.0"
+description = "IAM, SSO, GDPR and RBAC suite for Ferrox ecosystem."
+authors = [{ name = "AI-Autistic-Intelligence" }]
+readme = "README.md"
+requires-python = ">=3.11"
+dependencies = [
+    "ferrox-py>=1.0.0",
+    "pydantic>=2.0"
+]