Ergebnisse 1-3 + Typs Debug
This commit is contained in:
@@ -0,0 +1,533 @@
|
||||
# New Use-Cases Discovered from Screenshot Analysis
|
||||
|
||||
**Generated**: 2025-11-23
|
||||
**Analysis Method**: Visual UI inspection of captured screenshots
|
||||
**Status**: Initial findings from first screenshot
|
||||
**Screenshot Count**: 1 of 34
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
Initial screenshot analysis of CentronNexus has revealed **1 critical new use-case** not documented in existing documentation files:
|
||||
|
||||
### NEW: Authentication & User Login System
|
||||
|
||||
This use-case represents a critical system component that must precede all other functionality in CentronNexus. Every user interaction with the system is predicated on successful authentication through this workflow.
|
||||
|
||||
---
|
||||
|
||||
## Use-Case #1: Authentication & User Login (System/Security)
|
||||
|
||||
### Classification
|
||||
- **Category**: System / Security
|
||||
- **Module**: Authentication Service
|
||||
- **Priority**: P0 (Critical)
|
||||
- **Complexity**: Medium
|
||||
- **User Roles**: All users (required for system access)
|
||||
- **Status**: Discovered from screenshot, needs implementation documentation
|
||||
|
||||
---
|
||||
|
||||
### Overview
|
||||
|
||||
The ServiceBoard Authentication system provides a secure gateway to the entire CentronNexus platform. Users must successfully authenticate before accessing any feature, dashboard, or ticket functionality. The system supports two authentication methods:
|
||||
|
||||
1. **Enterprise SSO**: Microsoft Entra ID (Azure AD)
|
||||
2. **Traditional Login**: Username and password
|
||||
|
||||
### Key UI Elements (from screenshot)
|
||||
|
||||
1. **ServiceBoard Header**
|
||||
- Application branding
|
||||
- Logo and name identification
|
||||
- Tagline: "Ihr cleveres Ticketsystem" (Your smart ticket system)
|
||||
|
||||
2. **Authentication Options Section**
|
||||
- "Anmelden mit Microsoft" (Sign in with Microsoft) - Primary button
|
||||
- Alternative login header
|
||||
- Setup Wizard link
|
||||
|
||||
3. **Login Form**
|
||||
- Benutzername (Username) input field
|
||||
- Passwort (Password) input field
|
||||
- "Anmelden" (Sign In) button
|
||||
- Remember me checkbox (if present, not fully visible)
|
||||
|
||||
4. **Footer**
|
||||
- Version information (1.0.2601.301)
|
||||
- Datenschutz (Data Protection) link
|
||||
- Impressum (Legal/Imprint) link
|
||||
- Copyright notice
|
||||
|
||||
---
|
||||
|
||||
### Use-Cases
|
||||
|
||||
#### Use-Case 1A: User Login with Credentials
|
||||
|
||||
**Actor**: Employee, Support Agent, Manager
|
||||
**Precondition**: User has valid credentials; browser is at login page
|
||||
**Trigger**: User navigates to CentronNexus application
|
||||
|
||||
**Primary Flow**:
|
||||
1. System displays ServiceBoard login page
|
||||
2. User enters username in "Benutzername" field
|
||||
3. User enters password in "Passwort" field
|
||||
4. User clicks "Anmelden" button
|
||||
5. System validates credentials against user database
|
||||
6. System creates authenticated session with JWT token
|
||||
7. System initializes user permissions and role-based access
|
||||
8. System redirects to dashboard or home page
|
||||
9. User sees ticket list, dashboard, or assigned tickets
|
||||
|
||||
**Alternative Flow A: Invalid Credentials**:
|
||||
- At step 5: System finds credentials are invalid
|
||||
- System displays error message: "Ungültige Anmeldedaten" (Invalid credentials)
|
||||
- System remains on login page
|
||||
- User can retry with correct credentials
|
||||
|
||||
**Alternative Flow B: Account Locked**:
|
||||
- At step 5: User account is locked after N failed attempts
|
||||
- System displays: "Konto gesperrt - Kontaktieren Sie Ihren Administrator" (Account locked)
|
||||
- User must contact administrator to unlock account
|
||||
- Administrator unlocks account in system settings
|
||||
|
||||
**Alternative Flow C: Remember Me**:
|
||||
- At step 4: User checks "Anmeldedaten speichern" (Remember credentials)
|
||||
- System stores credentials securely in browser
|
||||
- Next login: System pre-fills username field
|
||||
- User enters password and clicks "Anmelden"
|
||||
|
||||
**Post-conditions**:
|
||||
- User is authenticated and logged into system
|
||||
- User permissions are initialized
|
||||
- Session timeout is set (default 30 minutes)
|
||||
- Audit log records successful login attempt
|
||||
|
||||
**Exception Handling**:
|
||||
- Network error during validation → Display retry message
|
||||
- Database unavailable → Display "System unavailable" message
|
||||
- Invalid session → Force re-authentication
|
||||
|
||||
---
|
||||
|
||||
#### Use-Case 1B: Microsoft Entra ID (Azure AD) Single Sign-On
|
||||
|
||||
**Actor**: Enterprise user, Microsoft 365 subscriber
|
||||
**Precondition**: User has Microsoft account; user is on login page
|
||||
**Trigger**: User clicks "Anmelden mit Microsoft" button
|
||||
|
||||
**Primary Flow**:
|
||||
1. System displays ServiceBoard login page
|
||||
2. User clicks "Anmelden mit Microsoft" button
|
||||
3. System redirects to Microsoft Entra ID login
|
||||
4. User enters Microsoft credentials (email + password)
|
||||
5. Microsoft verifies credentials
|
||||
6. User approves application access permissions
|
||||
7. Microsoft redirects back to ServiceBoard with auth token
|
||||
8. System validates Microsoft token
|
||||
9. System creates authenticated session
|
||||
10. System maps Microsoft AD groups to ServiceBoard roles
|
||||
11. System initializes permissions based on AD group membership
|
||||
12. System redirects to dashboard or home page
|
||||
|
||||
**Alternative Flow A: User Not in ServiceBoard Directory**:
|
||||
- At step 9: System checks for user in ServiceBoard database
|
||||
- User is not found
|
||||
- System displays: "Benutzer existiert nicht im System" (User not found)
|
||||
- Administrator must add user to ServiceBoard user directory first
|
||||
|
||||
**Alternative Flow B: Multi-Factor Authentication Required**:
|
||||
- At step 5: Microsoft requires MFA (2FA code, biometric, etc.)
|
||||
- User provides MFA confirmation
|
||||
- Process continues from step 6
|
||||
|
||||
**Post-conditions**:
|
||||
- User is SSO authenticated
|
||||
- User role and permissions set from AD group membership
|
||||
- SSO session established (can be longer than traditional login)
|
||||
- Audit log records successful SSO login
|
||||
|
||||
**Benefits**:
|
||||
- No password storage required
|
||||
- Centralized identity management
|
||||
- Automatic sync with Microsoft 365 groups
|
||||
- Compliance with enterprise security policies
|
||||
- Reduced password reuse issues
|
||||
|
||||
---
|
||||
|
||||
#### Use-Case 1C: Setup Wizard for New Installation
|
||||
|
||||
**Actor**: System administrator, initial setup user
|
||||
**Precondition**: CentronNexus is first-time deployed; no admin user exists
|
||||
**Trigger**: User clicks "Setup Wizard" link on login page OR system detects first run
|
||||
|
||||
**Primary Flow**:
|
||||
1. System displays login page with "Setup Wizard" link
|
||||
2. Administrator clicks "Setup Wizard"
|
||||
3. System launches configuration wizard
|
||||
4. Step 1: Create initial admin user
|
||||
- Username input
|
||||
- Password input (with complexity validation)
|
||||
- Confirm password
|
||||
5. Step 2: Configure authentication method
|
||||
- Option: Traditional login only
|
||||
- Option: Enable Microsoft Entra ID integration
|
||||
- If Entra ID: Enter client ID, secret, tenant ID
|
||||
6. Step 3: Email configuration (for notifications)
|
||||
- SMTP server
|
||||
- From address
|
||||
- Test email send
|
||||
7. Step 4: Database configuration
|
||||
- SQL Server connection string
|
||||
- Validate connection
|
||||
8. Step 5: Review and apply
|
||||
- Summary of configuration
|
||||
- "Finish" button to complete setup
|
||||
9. System initializes database schema
|
||||
10. System creates admin user
|
||||
11. System restarts application
|
||||
12. System displays login page
|
||||
13. Administrator logs in with newly created credentials
|
||||
|
||||
**Post-conditions**:
|
||||
- System is fully configured
|
||||
- Initial admin user is created
|
||||
- Database is initialized
|
||||
- First backup is created
|
||||
- System is ready for use
|
||||
- Audit log records initial setup completion
|
||||
|
||||
---
|
||||
|
||||
#### Use-Case 1D: Session Management & Timeout
|
||||
|
||||
**Actor**: Logged-in user
|
||||
**Precondition**: User is authenticated and logged into system
|
||||
**Trigger**: User interacts with system OR timer expires
|
||||
|
||||
**Primary Flow**:
|
||||
1. User logs in successfully (from 1A or 1B)
|
||||
2. System creates session with 30-minute timeout
|
||||
3. User performs actions (view tickets, update records, etc.)
|
||||
4. Each user action resets the timeout timer
|
||||
5. If user is idle for 30 minutes: timeout expires
|
||||
6. System invalidates session token
|
||||
7. On next user action: System detects invalid session
|
||||
8. System redirects to login page with message: "Sitzung abgelaufen" (Session expired)
|
||||
9. User logs in again
|
||||
|
||||
**Alternative Flow A: Explicit Logout**:
|
||||
- User clicks "Abmelden" (Logout) in top navigation
|
||||
- System invalidates session immediately
|
||||
- System redirects to login page
|
||||
- Session cookie is cleared
|
||||
|
||||
**Alternative Flow B: Remember Session**:
|
||||
- User has "Sitzung auf diesem Computer speichern" (Remember session) checked
|
||||
- Timeout extended to 7 days (if enabled)
|
||||
- Session persists across browser restart (if not cleared)
|
||||
|
||||
**Post-conditions**:
|
||||
- User session is cleared
|
||||
- User credentials are not stored
|
||||
- Session data is removed from server
|
||||
- Audit log records logout timestamp
|
||||
|
||||
---
|
||||
|
||||
### System Components
|
||||
|
||||
#### Frontend Components
|
||||
- **Login.razor**: Login page component (Blazor)
|
||||
- **AuthenticationLayout.razor**: Authentication layout
|
||||
- **LoginForm.razor**: Reusable login form component
|
||||
- **SetupWizard.razor**: Initial setup wizard component
|
||||
- **SessionTimeoutManager.ts**: JavaScript for timeout handling
|
||||
|
||||
#### Backend Services
|
||||
- **AuthenticationService**: Core authentication logic
|
||||
- Credential validation
|
||||
- Token generation/validation
|
||||
- Session management
|
||||
- **MicrosoftEntraIdService**: Azure AD integration
|
||||
- OAuth 2.0 flow
|
||||
- Token validation
|
||||
- Group membership mapping
|
||||
- **UserRightsService**: Permission initialization
|
||||
- Role assignment
|
||||
- Access control list (ACL) creation
|
||||
- Feature access validation
|
||||
- **AuditLogService**: Logging authentication events
|
||||
- Login attempts (success/failure)
|
||||
- Logout events
|
||||
- Session timeouts
|
||||
- Setup wizard completions
|
||||
|
||||
#### Database Tables
|
||||
- **User**: User account information
|
||||
- UserId (PK)
|
||||
- Username
|
||||
- PasswordHash (salted hash)
|
||||
- Email
|
||||
- LastLoginDate
|
||||
- IsActive
|
||||
- IsLocked
|
||||
- FailedLoginAttempts
|
||||
- **UserRole**: User-to-role mapping
|
||||
- UserId (FK)
|
||||
- RoleId (FK)
|
||||
- **UserSession**: Active session tracking
|
||||
- SessionId (PK)
|
||||
- UserId (FK)
|
||||
- TokenHash
|
||||
- CreatedDate
|
||||
- ExpiresDate
|
||||
- LastActivityDate
|
||||
- IPAddress
|
||||
- UserAgent
|
||||
|
||||
#### API Endpoints (CentronWebService)
|
||||
- `POST /api/authenticate` - Traditional login
|
||||
- `POST /api/authenticate/microsoft` - Microsoft SSO login
|
||||
- `POST /api/authenticate/validate` - Validate token
|
||||
- `POST /api/authenticate/refresh` - Refresh token
|
||||
- `POST /api/logout` - Logout (invalidate session)
|
||||
- `GET /api/user/profile` - Get current user info
|
||||
- `POST /api/setup/wizard` - Setup wizard endpoint
|
||||
- `POST /api/user/password/change` - Change password
|
||||
- `POST /api/user/password/reset` - Password reset
|
||||
|
||||
---
|
||||
|
||||
### Technical Implementation Details
|
||||
|
||||
#### Technology Stack
|
||||
- **Framework**: ASP.NET Core 8 (Blazor Server)
|
||||
- **Authentication**: OAuth 2.0, JWT (JSON Web Tokens)
|
||||
- **Hashing**: PBKDF2 or bcrypt for password hashing
|
||||
- **Encryption**: TLS 1.3 for transport security
|
||||
- **Session Storage**: Server-side (SQL Server or Redis)
|
||||
- **Frontend**: Razor components, C#, HTML/CSS/JavaScript
|
||||
|
||||
#### Security Features
|
||||
1. **Password Security**
|
||||
- Minimum 12 characters (configurable)
|
||||
- Mixed case, numbers, special characters required
|
||||
- Salted hash storage (not plain text)
|
||||
- Expiration policy (90 days, configurable)
|
||||
- History tracking (prevent reuse of last 5 passwords)
|
||||
|
||||
2. **Session Security**
|
||||
- JWT tokens with expiration
|
||||
- Session binding to IP address (optional)
|
||||
- Session binding to user agent (optional)
|
||||
- Secure HttpOnly cookies (no JavaScript access)
|
||||
- CSRF protection on login form
|
||||
|
||||
3. **Attack Prevention**
|
||||
- Account lockout after 5 failed attempts (15-minute lockout)
|
||||
- Rate limiting on login endpoint
|
||||
- Brute force detection and blocking
|
||||
- DDOS protection (if behind load balancer)
|
||||
- Input validation and sanitization
|
||||
|
||||
4. **Audit Trail**
|
||||
- All login attempts logged (success/failure)
|
||||
- Logout events logged
|
||||
- Session timeout logged
|
||||
- Password change logged
|
||||
- Failed MFA attempts logged
|
||||
- Admin actions logged
|
||||
|
||||
#### Integration Points
|
||||
- **Microsoft Entra ID**: OAuth 2.0 authorization code flow
|
||||
- **LDAP (Optional)**: Active Directory integration for on-premises
|
||||
- **SAML (Future)**: Enterprise SSO protocol
|
||||
- **MFA Providers (Future)**: Duo, Okta, etc.
|
||||
|
||||
---
|
||||
|
||||
### User Permissions & Role-Based Access Control (RBAC)
|
||||
|
||||
After successful authentication, the system initializes user permissions:
|
||||
|
||||
#### Roles (Examples)
|
||||
- **Administrator**: Full system access, user management, settings
|
||||
- **Support Manager**: Team management, ticket escalation, reports
|
||||
- **Support Agent**: Basic ticket operations, customer interaction
|
||||
- **Customer Portal User**: View own tickets, submit new tickets
|
||||
- **Guest**: Limited read-only access (if enabled)
|
||||
|
||||
#### Permission Initialization
|
||||
1. System retrieves user from database
|
||||
2. System retrieves user's assigned roles
|
||||
3. System retrieves permissions for each role
|
||||
4. System builds access control list (ACL)
|
||||
5. System stores ACL in JWT token or session
|
||||
6. All subsequent operations check ACL
|
||||
|
||||
#### Example Permission Categories
|
||||
- `Ticket.View`: Can view tickets
|
||||
- `Ticket.Edit`: Can edit ticket properties
|
||||
- `Ticket.Close`: Can close tickets
|
||||
- `Ticket.Assign`: Can assign tickets to users
|
||||
- `User.Manage`: Can create/modify users
|
||||
- `Report.View`: Can access reports
|
||||
- `Settings.Configure`: Can modify system settings
|
||||
|
||||
---
|
||||
|
||||
### Error Handling & User Messages
|
||||
|
||||
#### Login Error Messages
|
||||
| Error Code | Message | Cause |
|
||||
|-----------|---------|-------|
|
||||
| ERR_INVALID_CREDENTIALS | Ungültige Anmeldedaten | Wrong username or password |
|
||||
| ERR_ACCOUNT_LOCKED | Konto ist gesperrt | Account locked after failed attempts |
|
||||
| ERR_ACCOUNT_INACTIVE | Konto ist inaktiv | User account disabled by admin |
|
||||
| ERR_SESSION_EXPIRED | Sitzung abgelaufen | Session token expired |
|
||||
| ERR_INVALID_TOKEN | Ungültiger Token | Token validation failed |
|
||||
| ERR_SSO_FAILED | SSO-Anmeldung fehlgeschlagen | Microsoft SSO connection error |
|
||||
| ERR_SERVER_ERROR | Systemfehler | Unexpected server error |
|
||||
|
||||
---
|
||||
|
||||
### Data Flow Diagram
|
||||
|
||||
```
|
||||
User Browser CentronNexus Server External Systems
|
||||
| | |
|
||||
|----(1) Load Login Page-------->| |
|
||||
| | |
|
||||
|<---(2) Login Form HTML---------| |
|
||||
| | |
|
||||
|----(3) Enter Credentials------>| |
|
||||
| | |
|
||||
| (4) Validate Credentials |
|
||||
| (5) Check User Database |
|
||||
| (6) Generate JWT Token |
|
||||
| (7) Create Session |
|
||||
| | |
|
||||
|<---(8) Set-Cookie + Redirect---| |
|
||||
| | |
|
||||
|--OR-- (Microsoft SSO) -------->| |
|
||||
| |----(9) OAuth Redirect---->| Microsoft
|
||||
| | Entra ID |
|
||||
| |<---(10) Auth Token--------|
|
||||
| | |
|
||||
|<---(11) Redirect + Cookie------| |
|
||||
| | |
|
||||
|----(12) Access Dashboard------->| |
|
||||
| | |
|
||||
| (13) Verify Token |
|
||||
| (14) Load User Data |
|
||||
| (15) Initialize Permissions |
|
||||
| | |
|
||||
|<---(16) Dashboard HTML---------| |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Performance & Scalability Considerations
|
||||
|
||||
1. **Session Storage**
|
||||
- Consider Redis for distributed session caching
|
||||
- Reduces database load for frequent validation
|
||||
- Improves response time for token validation
|
||||
|
||||
2. **Token Validation**
|
||||
- Cache validation results briefly (10 seconds)
|
||||
- Reduces database queries for high-traffic scenarios
|
||||
- Slight trade-off: session invalidation delay
|
||||
|
||||
3. **Microsof Entra ID Integration**
|
||||
- Cache user group membership (5 minutes)
|
||||
- Reduces calls to Microsoft API
|
||||
- Background sync to detect role changes
|
||||
|
||||
4. **Rate Limiting**
|
||||
- Implement per-IP rate limiting (10 requests/minute per IP)
|
||||
- Implement per-username rate limiting (5 failed attempts in 15 minutes)
|
||||
- Use sliding window algorithm for smooth rate limiting
|
||||
|
||||
---
|
||||
|
||||
### Testing Considerations
|
||||
|
||||
#### Unit Tests
|
||||
- Credential validation logic
|
||||
- Token generation and validation
|
||||
- Permission initialization
|
||||
- Password hashing verification
|
||||
|
||||
#### Integration Tests
|
||||
- Full login flow (credential-based)
|
||||
- Full SSO flow (Microsoft Entra ID)
|
||||
- Session timeout and refresh
|
||||
- Concurrent session handling
|
||||
- Account lockout mechanism
|
||||
|
||||
#### Security Tests
|
||||
- SQL injection in login form
|
||||
- XSS in login error messages
|
||||
- CSRF token validation
|
||||
- Password hash security
|
||||
- Token signature validation
|
||||
|
||||
#### Performance Tests
|
||||
- Login throughput (transactions/second)
|
||||
- Session validation response time
|
||||
- SSO redirect time
|
||||
- Concurrent user session limit
|
||||
|
||||
---
|
||||
|
||||
### Recommendations for Implementation
|
||||
|
||||
1. **Prioritize This Use-Case**
|
||||
- Authentication is P0 (blocking all other features)
|
||||
- Should be implemented before any other module
|
||||
- Ensure security review before production
|
||||
|
||||
2. **Security Audit**
|
||||
- Review password hashing algorithm (recommend bcrypt)
|
||||
- Review token signing algorithm (recommend RS256 for JWT)
|
||||
- Implement rate limiting at endpoint level
|
||||
- Add security headers (CSP, X-Frame-Options, etc.)
|
||||
|
||||
3. **Testing**
|
||||
- Comprehensive security testing recommended
|
||||
- Penetration testing on authentication endpoints
|
||||
- Password complexity validation testing
|
||||
|
||||
4. **Documentation**
|
||||
- Add to main USE_CASES_CENTRON_NEXUS.md as Chapter 1.0
|
||||
- Create admin guide for user and role management
|
||||
- Create user guide for password reset and account management
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
The Authentication & User Login system is a **critical, previously undocumented use-case** that must precede all other CentronNexus functionality. This discovery highlights the importance of:
|
||||
|
||||
1. **Visual UI analysis**: Screenshots reveal system flows not immediately obvious from code
|
||||
2. **Complete documentation**: All critical paths must be documented, including authentication
|
||||
3. **Security-first design**: Authentication infrastructure is foundational to system security
|
||||
|
||||
The initial screenshot has successfully identified this gap in the documentation and provided detailed specifications for implementation and testing.
|
||||
|
||||
---
|
||||
|
||||
**Document Status**: Initial findings complete, ready for implementation planning
|
||||
**Next Steps**:
|
||||
1. Complete remaining 33 screenshots
|
||||
2. Analyze for additional undocumented use-cases
|
||||
3. Update main documentation files
|
||||
4. Prioritize authentication implementation
|
||||
|
||||
**Generated**: 2025-11-23
|
||||
**Version**: 1.0 - Initial Discovery
|
||||
Reference in New Issue
Block a user