Profile

In nevisIDM, profiles are used to give users different sets of roles and authorizations. During authentication a user who has more than one profile will have to choose which profile he wants to work with. For example: a user could have a profile with administrative rights for some rare tasks and another profile for the daily business. Doing so, the accidental use of certain administrative authorizations can be avoided as the user has to log out/log in to use the profile with administrative rights.

In summary, a profile has the following main characteristics:

• a user can have zero, one or more profiles.
• by means of profiles authorizations are assigned to users.
• a profile always belongs to exactly one unit. The user thus belongs to the unit to which his active profile belongs.
• because the user is assigned via profile to a unit, it is possible, e.g., to model dual mandates of users and the user can thus belong to two units.
• a user without any profile does not belong to any unit.

Profile state

A profile can be in one of three states: active, disabled or archived. The standard state is active. Disabled means that this profile cannot be used to log in at the moment. An archived profile cannot be used to log in either, but while a disabled profile can become active again, the process of archiving a profile cannot be reversed. Usually a profile has the same state as the user it belongs to since disabling/archiving a user will disable/archive all his profiles too. Beside this automatism it is possible to disable/archive a single selected profile of an active user.

Archiving a profile

Archiving will keep the name and IDs of the profile blocked so they cannot accidentally be reused. The authorizations held by the profile are automatically deleted. Once a profile has been archived, it can only be deleted physically, there is no other state transition from state "archived".

Database table TIDMA_PROFILE

DB attribute	Java data type (max. size), defaults	Description
client_id	Long, not NULL	Defines the client the profile belongs to. This information is redundant since a mapping between user and client exists too. However, the redundant information facilitates certain optimizations. Foreign key that links to information in the table TIDMA_CLIENT.
default_profile	Boolean, not NULL	Defines if the profile is the default profile of the user. The default profile is used for authentications where no interactions with the user can be performed. Instead of showing a selection view, the default profile is automatically chosen.
deputed_profile_id	Long, not NULL	Points to the deputed profile from which non-nevisIDM roles and properties are inherited. Foreign key that links to information in the table TIDMA_PROFILE.
extid	String(50), not NULL	External identifier
modification_comment	String(1000), nullable	Comment of related add/update/delete action.
name	String(100), not NULL	Name of the profile.
profile_id	Long, not NULL	Primary key (uniquely identifies each individual DB entry)
remarks	String(1000), nullable
state_id	Long, not NULL	The ID of the state. The available states are: active; deactivated; archived
unit_id	Long, not NULL	Foreign key that links to information in the table TIDMA_UNIT. Defines the unit the profile belongs to.
user_id	Long, not NULL	Defines the user the profile belongs to. Foreign key that links to information in the table TIDMA_USER.
valid_from	Date, nullable	The profile is valid from the valid_from date onward. If this date is in the future, the profile is not allowed to log in (similar to the "deactivated" setting of the state_id attribute). The "Null" value means no restriction.
valid_to	Date, nullable	The profile is valid until the valid_to date. If this date is in the past, the profile is not allowed to log in (similar to the "deactivated" setting of the state_id attribute). The "Null" value means no restriction.