ESM login process with ESA
Learn about the ESA login process for accessing the ESM platform.
ESM login process with ESA
Learn about the ESA login process for accessing the ESM platform.
Login process with Secure Access
Describes a process where the ESM reads and processes information from a user's login request with Secure Access (ESA).
- ESM checks if the userPrincipal name from request is NULL. If it's NULL, the ESM rejects login.
- Next ESM reads the
esm_userLevelfrom request. If it's NOACCESS, the ESM rejects login. Userlevel is coming from Secure Access (ESA), it can be missing if not in use. Then this step is skipped. Secure Access (ESA) is sending UserLevel as Normal, Root or NOACCESS. - If the user (NOT Person) with the same principal name already exists, the ESM proceeds to check if the
servlet.auth.create.usersflag is set to FALSE. If it is, and user is not found the ESM rejects the login. - If the User is not found, ESM tries to create it if the
servlet.auth.create.usersflag is set to TRUE. It checks for the matching person (by principal name) and creates a User data card if none is found. If the user creation encounters any errors or duplicates with the same name, the ESM rejects the login. - The ESM confirms that User and Person are connected through a property
servlet.auth.person.user.attribute.code(default value:efecte_user). If there is no User in that reference, the ESM rejects the login. - If there are any problems creating The User, the ESM rejects login. However, it checks if user was created/edited by the installer/administrator.
- If the Person that should be linked to a User is NOT present, the ESM tries to create a Person data card and link it to the User.
- The ESM tries to read the user level from request (if present in SAML message). If there is still no Person created, the ESM assigns READONLY level automatically. Otherwise the ESM iterates over the groups assigned to the Person (property name is set in
servlet.auth.person.groups.attribute.code, default value: "groups").- If one of the groups is equal to
servlet.auth.admin.ad.group(default value: "Matrix42 Administrator"), the ESM gives ROOT level access - If one of the groups is equal to
servlet.auth.user.ad.group(default value: "Matrix42 User"), the ESM gives NORMAL level - Otherwise, the ESM gives READONLY level
- If one of the groups is equal to
- If there was any
esm_userLevelsent in the request, the ESM assigns roles to the User. ESM reads therolesSAML attribute and replaces all of the User's roles with the roles matching the attribute values (matched via External Identifier). Any previously assigned roles not present in the SAML message are removed. - Finally the ESM acts differently according to the User level set previously.
- If the User level was set to NORMAL or ROOT, and the User was actually created during the request handling, and there was no
esm_userLevelsent in the SAML message, the ESM will try to assign that User default role, set with System property:servlet.auth.user.roles(default value: Support person). - If the User level was set to NORMAL or ROOT, the user already existed (was not created during this request), and there was no
esm_userLevelin the SAML message, the ESM does not change the User's roles. Any roles previously assigned in ESM remain unchanged. - If the User level was set to READONLY and
esm_userLevelwas NOT sent with SAML message, the ESM will try to addservlet.auth.user.readonly.rolesroles to that User.
- If the User level was set to NORMAL or ROOT, and the User was actually created during the request handling, and there was no
Role assignment summary
| Scenario |
esm_userLevel in SAML |
roles in SAML |
Result | Saved to DB |
|---|---|---|---|---|
| New user, userLevel present | Yes | Yes | All roles set from roles attribute via External Identifier matching |
Yes, on every login |
| New user, userLevel present | Yes | Empty / missing | All roles cleared | Yes |
| New user, no userLevel | No | Ignored | Default role assigned — configured in ESM platform setting servlet.auth.user.roles (default: Support person) |
Yes, once on creation |
| Existing user, userLevel present | Yes | Yes | All roles replaced by roles attribute via External Identifier matching |
Yes, on every login |
| Existing user, userLevel present | Yes | Empty / missing | All roles cleared | Yes |
| Existing user, no userLevel | No | Ignored | Roles unchanged — whatever was last saved in DB remains | No change |
Table of Contents