Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/carlamndz/InventarioITU/llms.txt

Use this file to discover all available pages before exploring further.

InventarioITU does not manage its own user database. Instead, every login attempt is validated against the institutional directory — either OpenLDAP or a compatible Active Directory server — through the ldap-service container running on port 389. This design means user accounts, password policies, and group memberships are controlled centrally by ITU Mendoza’s existing IT infrastructure, and the inventory system automatically inherits those controls. The Node.js/Express backend on inventario-web acts as the LDAP client: it receives the submitted credentials, performs an LDAP bind, and grants or denies a session based on the directory’s response.

​
How Authentication Works

1

User submits the login form

The user opens inventario-web in a browser (port 3000) and enters their ITU username and password. The form POSTs the credentials to the Express login endpoint.
2

Express initiates an LDAP bind

The backend first performs an administrative bind using the service account credentials (LDAP_BIND_DN / LDAP_BIND_PASSWORD) to search the directory for the user’s distinguished name (DN). It then attempts a second bind with the user’s own DN and the submitted password.
3

OpenLDAP validates the credentials

The ldap-service container (port 389) receives the bind request and checks the provided DN and password against its directory database. It returns either a success response or an invalidCredentials error.
4

Session is created or the user is redirected

On a successful bind, the Express backend creates a server-side session, stores the user’s DN and group membership, and redirects to the inventory dashboard. On failure, the user is redirected back to the login page with an error message — no session is written and no internal details are exposed to the browser.

​
Authentication Flow Diagram

The credential path from browser to directory involves three hops:
LayerServicePortAction
ClientBrowser—Submits username + password via POST
Frontendinventario-web3000Receives credentials; issues LDAP bind request
Directory clientldap-service389Validates bind against OpenLDAP directory
Directory storeOpenLDAP / AD—Returns success or invalidCredentials
Browser
  │  POST /login (username, password)
  ▼
inventario-web :3000  (Node.js / Express)
  │  ldap_bind(userDN, password)
  ▼
ldap-service :389  (OpenLDAP)
  │  directory lookup
  ▼
OpenLDAP / Active Directory
  │  bind success / invalidCredentials
  └──────────────────────────────────▶  session granted or login redirect

​
User Roles

InventarioITU recognises two roles, mapped from LDAP group membership at login time:

Admin

Members of the inventario-admins LDAP group. Can create, edit, and delete equipment records in both the relational database and MongoDB, manage user assignments, and access all reports.

Viewer

All other authenticated users. Can browse the full equipment inventory, search by lab or equipment ID, and view hardware component details — but cannot modify any records.
Group membership is checked once at login and stored in the session. If a user’s group membership changes in LDAP, they must log out and log back in for the new role to take effect.

​
LDAP Connection Configuration

The Express backend reads all LDAP connection parameters from environment variables. No connection string or credential should ever appear in source code or in a committed configuration file.
VariableExample valuePurpose
LDAP_URLldap://ldap-service:389Full URL of the LDAP server, including scheme and port
LDAP_BASE_DNdc=itu,dc=edu,dc=arBase distinguished name under which all user entries are searched
LDAP_BIND_DNcn=inventario-svc,ou=services,dc=itu,dc=edu,dc=arDN of the service account used for the initial directory search
LDAP_BIND_PASSWORD(secret)Password for the LDAP_BIND_DN service account
In a Kubernetes deployment these values are injected from a Secret object referenced in the inventario-web Pod spec. A minimal environment block looks like: 
# Example: env block for the inventario-web Pod spec (add to k8s/frontend/deployment.yaml)
env:
  - name: LDAP_URL
    value: "ldap://ldap-service:389"
  - name: LDAP_BASE_DN
    value: "dc=itu,dc=edu,dc=ar"
  - name: LDAP_BIND_DN
    valueFrom:
      secretKeyRef:
        name: ldap-credentials
        key: bind-dn
  - name: LDAP_BIND_PASSWORD
    valueFrom:
      secretKeyRef:
        name: ldap-credentials
        key: bind-password
Never commit LDAP_BIND_DN or LDAP_BIND_PASSWORD to version control. These credentials grant read access to the entire directory tree. Use a Kubernetes Secret (or an external secrets manager) and ensure the ldap-credentials secret is created manually on each cluster — it must not be part of any checked-in manifest.
For instructions on deploying and configuring the ldap-service container itself — including how to seed the initial directory, configure TLS, and set up replication — see the full setup guide at /operations/ldap-configuration.

Build docs developers (and LLMs) love

Get started for freeTalk to us