Below is a detailed Project Requirements Document for your centralized authentication and RBAC-enabled microservices system for myHospitalnow. This document is structured for clarity and sharing with your technical or business stakeholders, following the approach and design discussed.
Project Requirements Document
Centralized Authentication & RBAC for myHospitalnow Microservices
Date: July 2, 2025
1. Project Overview
myHospitalnow is a healthcare platform with three primary user types—Patients, Doctors, and Hospitals—each accessing distinct portals and features. The project aims to implement a centralized authentication and authorization system using JWT and RBAC, ensuring secure, seamless access across all microservices and portals.
2. Objectives
- Provide a single, secure login for all user types (Patients, Doctors, Hospitals, Nurses).
- Enforce Role-Based Access Control (RBAC) for all APIs and resources.
- Support stateless, scalable authentication using JWT tokens.
- Enable future extensibility (e.g., adding new user roles, mobile apps, or external IdP integration).
- Ensure compliance with security best practices (zero trust, least privilege, audit logging).
3. Functional Requirements
3.1 User Authentication
- Single login endpoint for all user types.
- Support for login, registration, logout, and password reset.
- JWT token issuance on successful authentication.
- Token refresh capability for session continuity.
- Centralized login page accessible from all portals.
3.2 Role-Based Access Control (RBAC)
- Define roles: Patient, Doctor, Hospital, Nurse, Admin.
- Assign roles at user creation or via admin interface.
- Enforce access permissions based on roles for all API endpoints.
- Ability to update roles and permissions dynamically.
3.3 User Management
- User registration for all roles.
- Profile management (view/update personal and professional details).
- Password management (reset, change).
- Role assignment and modification by authorized admins.
3.4 Resource Microservices
- Separate microservices for:
- Patient Portal (
/)
- Doctor Portal (
/doctors/)
- Hospital Portal (
/hospitals/)
- Nurse Portal (
/nurses/)
- Microservices delegate authentication and authorization to centralized services.
- Each service exposes APIs for its domain functions (bookings, listings, etc.).
3.5 API Gateway
- Central entry point for all client requests.
- Validates JWT tokens and propagates user claims.
- Routes requests to appropriate microservices.
- Handles rate limiting, logging, and error handling.
3.6 Central Identity Store
- Store user accounts, roles, and permissions in a secure MySQL database.
- Support for audit logging of authentication and authorization events.
3.7 Mobile App Integration
- Android apps for Patients, Doctors, and Hospitals.
- All apps use the same authentication and authorization infrastructure.
3.8 (Optional) External Identity Provider Integration
- Support for SSO with Google, Azure AD, or LDAP via OAuth2/OpenID Connect.
4. Non-Functional Requirements
- Security: HTTPS enforced, secure token storage, password hashing (bcrypt/argon2).
- Scalability: Stateless authentication, horizontally scalable services.
- Extensibility: Easy to add new user types or portals.
- Maintainability: Modular codebase, clear separation of concerns.
- Auditability: Centralized logging for all auth events.
5. Technical Approach & Architecture
5.1 Technology Stack
- Backend: Laravel (PHP), MySQL
- Frontend: Web (Laravel Blade/Vue/React), Android (Flutter/Native)
- Authentication: JWT (via
php-open-source-saver/jwt-auth), optional OAuth2 (Laravel Passport)
- RBAC: Spatie Laravel Permission package
- API Gateway: Laravel-based routing (for local), NGINX/Kong (for production)
- Hosting: XAMPP for local development
5.2 High-Level Architecture Diagram
User → [API Gateway] → [Auth Service] → [JWT Token Issued]
↓ ↓
[Resource Microservices: Patient, Doctor, Hospital, Nurse]
↓
[Central Identity Store (MySQL)]
5.3 Authentication Flow
- User visits any portal (
/, /doctors/, /hospitals/).
- User is redirected to a centralized login page (e.g.,
/auth/login).
- User submits credentials; Auth Service validates and issues a JWT containing role and claims.
- JWT is stored in a secure, HTTP-only cookie or sent to the mobile app.
- All subsequent API requests include the JWT (via header or cookie).
- API Gateway validates the JWT and propagates claims to microservices.
- Resource microservices enforce RBAC based on claims.
5.4 RBAC Enforcement
- Roles and permissions are stored centrally.
- Each API endpoint is protected via middleware that checks for required roles/permissions.
- Admins can update roles/permissions without code changes.
6. Results & Benefits
- Unified login experience for all users.
- No session conflicts between portals—users can access all permitted areas with one token.
- Secure, scalable authentication with stateless JWTs.
- Fine-grained access control via RBAC.
- Centralized audit logging for compliance and monitoring.
- Future-ready: Easily add new user types, portals, or SSO integrations.
7. Implementation Notes
- Use php-open-source-saver/jwt-auth for JWT handling.
- Use Spatie Laravel Permission for RBAC.
- Store tokens securely; use HTTPS.
- All user management and authentication logic resides in the central Auth Service.
- All microservices validate JWTs and enforce RBAC via middleware.
- API Gateway can be implemented with Laravel routing for local development; upgrade to a dedicated gateway for production.
8. Open Questions / Next Steps
- Finalize user role definitions and permissions matrix.
- Decide on SSO provider integration (if required).
- Plan for migration of existing users to the new system.
- Schedule security review and penetration testing.
Prepared by:
[Your Name/Team]
myHospitalnow Technical Team
If you need this in a specific format (Word, PDF, etc.), or want example code or diagrams included, let me know!