Skip to main content
A profile (Perfil) is the unit of access control in WebCorporativa. Instead of assigning permissions directly to individual users, you assign a profile to each user. The profile determines everything that user is allowed to do.

​
Profile model

The following fields make up a profile record:
FieldTypeConstraintsDescription
IdPerfilintPrimary key, auto-generatedUnique profile identifier
strNombrePerfilstringRequired, max 80 charsDisplay name for the profile
BitAdministradorboolDefault: falseWhen true, grants all permissions on all modules automatically
public class PerfilModel
{
    [Key]
    public int IdPerfil { get; set; }
    [Required, MaxLength(80)]
    public string strNombrePerfil { get; set; }
    public bool BitAdministrador { get; set; } = false;
    public ICollection<PermisosPerfilModel> PermisosPerfilModels { get; set; }
}

​
Administrator flag

When BitAdministrador is true, the API automatically injects permission claims for every registered module into the JWT at login time. You do not need to configure individual module permissions for an administrator profile — they are granted implicitly.
Setting BitAdministrador = true bypasses all per-module permission checks. Assign this flag only to profiles that genuinely require unrestricted system access.
When BitAdministrador is false, access is limited to the module permissions explicitly granted via POST /api/PermisosPerfil. Any module action not explicitly granted returns 403 Forbidden. See Permissions for the full bypass logic and how the esAdmin claim is set in the token.

​
One profile per user

Every user has exactly one active profile at a time, set by the IdPerfil field on the user record. You assign the profile when creating the user. To change a user’s access level, update their IdPerfil — the change takes effect on their next login, when a new token is issued with the updated permission set.
Changing a user’s profile does not invalidate their current JWT. The old token remains valid until it expires (30 minutes). Plan profile changes accordingly in time-sensitive scenarios.

​
Profile → PermisosPerfil → Modulos

Profiles do not store permissions directly. Instead, they are linked to modules through a join table: Each PermisosPerfilModel row ties one profile to one module and specifies which of the five actions (agregar, editar, consulta, eliminar, detalle) are enabled for that combination.

​
Managing profiles

Profiles are managed through the /api/Perfil endpoints:

List profiles

Retrieve all profiles registered in the system.

Create a profile

Create a new profile with a name and optional administrator flag.

Update a profile

Rename a profile or toggle the BitAdministrador flag.

Delete a profile

Remove a profile. Users assigned to the deleted profile will lose their access on next login.
To assign or update module-level permissions for a profile, use the Permissions endpoints.

​
Default seeded profile

The API seeds one profile on first startup:
FieldValue
strNombrePerfilAdministrador Master
BitAdministradortrue
This profile is assigned to the default admin user. It cannot be removed without first reassigning or removing all users attached to it.

Modules

What modules are and how the Clave field maps to permission strings.

Users

How users are created and how profile assignment works.

Permissions

How permission strings are enforced at the endpoint level.

Permissions API

Save and retrieve per-profile module permissions.

Build docs developers (and LLMs) love

Get started for freeTalk to us