User Access & Identity Management

Business perspective: User Access & Identity Management

1. Business Summary

Authenticates internal users, vendors and candidates, manages multi-brand login (one credential → multiple personas), supports login-as / on-behalf, password reset, SSO-style ingestion via Cognito Forms, and stores per-user session preferences (language, theme, timezone, ownCloud credentials).

2. Business Value

Single point of access protecting confidential commercial, financial and personnel data. Enables a large, distributed workforce to work across multiple brands and tools (web, mobile, ownCloud, TMS).

3. Users / Stakeholders

Employees, project managers, account managers, sales agents, finance, vendor managers, freelancers/agencies, candidates, system administrators.

4. Workflows

A. Standard login
- Trigger: users/translogin form post.
- Steps: AuthComponent matches credentials against logins table → resolves User rows by User.login_id → if multiple users (multi-brand), populates Auth.User.users and Auth.User.brands arrays in session → loads timezone via User.Contact.Address.Country, last-login, picture → sets ownCloud cookies (owncloud_user_id, owncloud_auth_user, owncloud_auth_pass, main_folder, db_name) → optionally sets TMS_integration flag → redirects to home.
- Result: Authenticated session with role + brand + entity context.
- Exceptions: Resigned users blocked; disabled logins blocked at AuthComponent layer.

B. Login-as / On-behalf
- Trigger: Admin or substitute selects another user.
- Steps: Session retains basicUser (original) plus on_behalf_id (effective) → SecurityCronJobs honor basicUser as audit attribution while on_behalf_id drives privilege checks.
- Result: Audit trail preserves both identities.

C. Password reset
- Trigger: Token-bearing URL users/reset_password?token=....
- Steps: Token looked up in logins.token; new password hashed and persisted; token cleared.
- Result: Password updated; session re-established.
- Exceptions: No expiry on reset tokens (Observed in code).

D. Cognito Forms ingestion
- Trigger: External Cognito Forms webhook POSTs JSON to cognito/base.
- Steps: Match by email → create/update Contact + Resource + Candidate → download attached CV / certificates and store in ownCloud → log into CognitoLog.
- Result: Self-service onboarding of candidates.

5. Sub-Features

  • Multi-user/multi-brand login.
  • Login-as / on-behalf substitution.
  • Token-based password reset.
  • ownCloud credential propagation.
  • Cognito Forms recruitment ingest.
  • Resource picture/last-login update.

6. Business Rules

  • Session-scoped basicUser and on_behalf_id track substitution.
  • is_admin (User table) bypasses row-level security checks.
  • TMS integration flag sourced from system_settings.
  • Cookies hold MD5-hashed password and ownCloud password (UsersController::translogin).

7. Data Entities

  • User — main person record with brand, department, contact, picture, last_login.
  • Login — credential (login_id, password, token).
  • Resource — extends User context for vendors/freelancers.
  • Contact / Address / Country — used for timezone derivation and addresses.
  • CognitoLog — webhook audit log.

8. Entry Points

  • Web: users/translogin, users/reset_password, users/logout.
  • Webhook: cognito/base (Cognito Forms), cognito/tryBase (test).
  • Internal API: users/me, users/getNew*.
  • Mobile: mobile_apis/login (basic HTTP auth).

9. Inputs & Outputs

  • Inputs: username/password, token, JSON form payload, mobile API credentials.
  • Outputs: authenticated session, Auth cookies, ownCloud credentials, log records.

10. Integrations

  • Cognito Forms: webhook (no retry, fire-and-forget).
  • ownCloud: credential cookies for cross-app SSO.
  • TMS: integration flag in session.

11. Calculations / Logic

None financial. Timezone derivation: User → Contact → Address → Country.timezone.

12. Status Lifecycle

  • Login: active / disabled / token-issued.
  • User: active / inactive / resigned.

13. Permissions

  • Admins manage logins/users.
  • is_admin bypasses many checks.
  • Substitution gated by configuration (no hard rule observed in source).

14. Reports & KPIs

  • last_login per user.
  • Cognito submission counts.

15. Risks & Observations

  • MD5 password copy in cookie (UsersController.php translogin) — easily reversible and replayable.
  • Reset tokens never expire (UsersController::reset_password).
  • Cognito ingest hard-codes manager IDs for specific forms (e.g., 27, 70).
  • No multi-factor authentication observed.
  • Multi-brand login allows one credential to switch persona; brand switch not audited.

16. Source Code Evidence

  • app/Controller/UsersController.php — translogin, reset_password, multi-user/brand block (~lines 226–449).
  • app/Controller/CognitoController.php — base(), tryBase(), Cognito → Resource provisioning.
  • app/Controller/LoginsController.php — buildRelations, manager/department relations.
  • app/Controller/AppController.php — global beforeFilter wiring.

← Deep dives index