Functional authorization - nevisIDM roles

Functional authorization checks authorization for an operation and is integrated into the nevisIDM roles. The table lists the standard nevisIDM roles. These roles are usually assigned to a standard user of nevisIDM. There is a second category of roles, the technical nevisIDM roles, listed in [the table] below.

Name	Descriptions / authorized objects
AppAdmin	Applications, roles, properties, property values Administrates all applications, can assign all application data rooms (can create MainAppOwners)
AppOwner	Assigns application role
Helpdesk	Limited UserAdmin functionality, but can handle credentials
MainAppOwner	Can assign application roles, can assign application data room (can create AppOwners)
Root	Can access everything
ClientRoot	Can access everything in own client but cannot administrate clients.
SelfAdmin	User's own data and credentials
UserAdmin	Can access and create users and profiles.
UserAndUnitAdmin	Like UserAdmin, but can also access Units and make new UserAdmins.
TemplateAdmin	Can manage text templates.
EnterpriseRoleAdmin	Can create enterprise roles with property values. Can assign member roles to enterprise roles. Can assign enterprise roles to profiles. Can assign enterprise role data rooms (can create EnterpriseRoleOwner).
EnterpriseRoleOwner	Can assign enterprise roles to profiles.

Name	Descriptions / authorized objects
BatchJobAdmin	Batch jobs
SoapTechAccess	Almost like root
SoapTechAccessReadOnly	Like SoapTechAccess but read only
TechUser	A technical role without any nevisIDM privileges. It can be used to mark technical users. A well-known use case is to check whether a user has this role when he wants to access a back end such as a SOAP interface. The check can be performed on the proxy, e.g., on nevisProxy with a SecurityRoleFilter. Alternatively, instead of the role-based model, create a technical user with the isTechnicalUser flag set.
Impersonator	A technical role only available for technical users. It allows them to impersonate another user.

Elementary rights of nevisIDM roles

A role is mapped to a set of elementary permissions allowing the execution of specific operations. These permissions are also called "elementary rights". Descriptions of all elementary rights can be found in [Appendix A]. An insight into the authorization mechanism of nevisIDM is given in the table. It shows default mappings of product roles to elementary rights.

The letters in the table represent the following:

• X: access without any additional authorization checks (only true for client-/unit-/app-global)
• c: if client authorization check is successful
• u: if unit data room authorization check is successful
• a: if application data room authorization check is successful
• e: if enterprise role data room authorization check is successful
• s: only to his own data

The table below has become somewhat famous within Nevis and is often referred to as "nevisIDM Chrüzlistich". It is Swiss-German and means "the table with a lot of crosses in it".

Roles/Rights	nevisIdm. Root	nevisIdm. ClientRoot	nevisIdm. UserAdmin	nevisIdm. UserAndUnit Admin	nevisIdm. AppAdmin	nevisIdm. AppOwner	nevisIdm. MainAppOwner	nevisIdm. Helpdesk	nevisIdm. Template Admin	nevisIdm. SelfAdmin	nevisIdm. SoapTechAccess	nevisIdm. SoapTechAccess ReadOnly	nevisIdm. TechUser	nevisIdm. Impersonator	nevisIdm. EnterpriseRole Admin	nevisIdm. EnterpriseRole Owner
ApplicationCreate	X	c			c						c
ApplicationDelete	X	c			c						ca
ApplicationModify	X	c			c						ca
ApplicationSearch	X	c			c	c	c	c			c	c			c	c
ApplicationView	X	c	ca	ca	c	ca	ca	c			ca	ca			c	c
AuthorizationApplCreate	X	c			c		cua				cua
AuthorizationApplDelete	X	c			c		cua				cua
AuthorizationApplSearch	X	c	cu	cu	c		cu	cu			c	c			c
AuthorizationApplView	X	c			c		cua	cu			cua	cua			c
AuthorizationClientCreate	X	c		cu	c		cua				cu				c
AuthorizationClientDelete	X	c		cu	c		cua				cu				c
AuthorizationClientSearch	X	c	cu	cu	c		cua				c	c			c
AuthorizationClientView	X	c		cu	c		cua				cu	cu			c
AuthorizationCreate	X	c	cu	cu	c	cua	cua				cua				c
AuthorizationDelete	X	c	cu	cu	c	cua	cua				cua				c
AuthorizationModify	X	c		cu	c		cua				cua				c
AuthorizationSearch	X	c	cu	cu	c	ca	ca	ca			c	c			c	cu
AuthorizationEnterpriseRoleCreate	X	c									cue				c
AuthorizationEnterpriseRoleDelete	X	c									cue				c
AuthorizationEnterpriseRoleSearch	X	c	cu	cu	c		c	cu			c	c			c	cue
AuthorizationEnterpriseRoleView	X	c			c		c	cu			cue	cue			c	cue
AuthorizationUnitCreate	X	c		cu			cu				cu				c
AuthorizationUnitDelete	X	c		cu			cu				cu				c
AuthorizationUnitSearch	X	c	cu	cu	c		c	cu			c	c			c
AuthorizationUnitView	X	c		cu	c		cu	cu			cu	cu			c
AuthorizationView	X	c	cu	cu	c	ca	ca	cu			cua	cua			c	cu
BatchJobExecute	X	c									X
BatchJobView	X	c									X
ClientApplAssign	X	c			c						ca
ClientApplDelete	X	c			c						ca
ClientApplView	X	c	c	ca	c	ca	ca	c			ca	ca
ClientCreate	X										X
ClientDelete	X										c
ClientModify	X										c
ClientSearch	X	c	c	c	c	c	c	c	c		c	c			c	c
ClientView	X	c	c	c	c	c	c	c	c		c	c			c	c
CollectionCreate	X	c									X
CollectionDelete	X	c									X
CollectionModify	X	c									X
CollectionView	X	c	X	X	X	X	X	X	X		X	X			c	c
ConsentView	X	X									X
CredentialChangeState	X	c						cu			cu
CredentialCreate	X	c						cu			cu
CredentialDelete	X	c	cu	cu				cu			cu
CredentialModify	X	c						cu			cu
CredentialPdfView	X	c
CredentialSearch	X	c						cu			cu	cu
CredentialView	X	c						cu			cu	cu
CredentialViewPlainValue	X	c									cu
EnterpriseAuthorizationCreate	X	c									cue				c	cue
EnterpriseAuthorizationDelete	X	c									cue				c	cue
EnterpriseAuthorizationModify	X	c									cue				c	cue
EnterpriseAuthorizationSearch	X	c	cu	cu	c	c	c	cu			cue	cue			c	cue
EnterpriseAuthorizationView	X	c	cu	cu	c	c	c	cu			cue	cue			c	cue
EnterpriseRoleCreate	X	c									c				c
EnterpriseRoleDelete	X	c									ce				c
EnterpriseRoleModify	X	c									ce				c
EnterpriseRoleSearch	X	c	c	c	c	c	c	c			ce	ce			c	ce
EnterpriseRoleView	X	c						c			ce	ce			c	ce
EnterpriseRoleMemberCreate	X	c									cae				c
EnterpriseRoleMemberDelete	X	c									cae				c
EnterpriseRoleMemberSearch	X	c						c			cae	cae			c	ce
EntityAttributeAccessOverride	X	c
GenerateReport	X	c
HistoryView	X	x									X	X
LoginIdOverride	X	c
LoginIdModify	X	c	cu	cu						s	cu
PersistentQueueView	X	c									c	c
PersistentQueueDelete	X	c									c
PersonalQuestionCreate	X	c									c
PersonalQuestionDelete	X	c									c
PersonalQuestionModify	X	c									c
PersonalQuestionView	X	c	c	c	c	c	c	c	c	c	c	c	c	c	c	c
PersonalQuestionSearch	X	c	c	c	c	c	c	c	c	c	c	c	c	c	c	c
PolicyConfigurationCreate	X	c									c
PolicyConfigurationDelete	X	c									c
PolicyConfigurationModify	X	c									c
PolicyConfigurationSearch	X	c									c	c
PolicyConfigurationView	X	c									c	c
ProfileArchive	X	c	cu	cu							cu
ProfileCreate	X	c	cu	cu							cu
ProfileDelete	X	c									cu
ProfileModify	X	c	cu	cu							cu
ProfileSearch	X	c	c	c	c	c	c	c			cu	cu			c	cu
ProfileView	X	c	cu	cu	c	cu	cu	cu			cu	cu			c	cu
DeputyCreate	X	c								s
DeputyDelete	X	c								s
PropertyAllowedValueCreate	X	c			X						X
PropertyAllowedValueDelete	X	c			X						X
PropertyAllowedValueModify	X	c									X
PropertyAllowedValueSearch	X	c	X	X	X	X	X	X			X	X			c	c
PropertyAllowedValueView	X	c			X	X	X				X	X			c	c
PropertyAttributeAccessOverride	X	c
PropertyCreate	X	c			X						X
PropertyDelete	X	c			X						X
PropertyModify	X	c			X						X
PropertySearch	X	c	X	X	X	X	X	X	X		X	X			c	c
PropertyValueCreate	X	c			X						X				c
PropertyValueDelete	X	c			X						X				c
PropertyValueModify	X	c			X						X				c
PropertyValueSearch	X	c	X	X	X	X	X	X			X	X			c	c
PropertyValueView	X	c			X	X	X				X	X			c	c
PropertyView	X	c			X	X	X				X	X			c	c
RoleCreate	X	c			c						ca
RoleDelete	X	c			c						ca
RoleModify	X	c			c						ca
RoleSearch	X	c	c	c	c	ca	ca	c			ca	ca			c	c
RoleView	X	c	c	c	c	c	c	c			ca	ca			c	c
SearchResultsExport	X	c	X	X	X	X	X	X							c	c
SelfAdmin	X	c								X	X	X
TemplateCreate	X	c							X		X
TemplateDelete	X	c							X		X
TemplateModify	X	c							X		X
TemplateStore	X	c							X		X	X
TemplateTextCreate	X	c							X		X
TemplateTextDelete	X	c							X		X
TemplateTextModify	X	c							X		X
TemplateTextView	X	c							X		X	X
TemplateView	X	c							X		X	X
TermsCreate	X	X									X
TermsDelete	X	X									X
TermsModify	X	X									X
TermsView	X	X									X
UnitCreate	X	c		cu							cu
UnitCreateTopUnit	X	c									cu
UnitDelete	X	c		cu							cu
UnitModify	X	c		cu							cu
UnitSearch	X	c	cu	cu	c	cu	cu	cu			cu	cu			c	cu
UnitView	X	c		cu	c			cu			cu	cu			c
UnitCredPolicyCreate	X	c		c							c
UnitCredPolicyDelete	X	c		c							c
UnitCredPolicyView	X	c		c							c
UserArchive	X	c	cu	cu							cu
UserCreate	X	c	cu	cu							cu
UserDelete	X	c									cu
UserModify	X	c	cu	cu				cu			cu
UserSearch	X	c	c	c	c	c	c	c			cu	cu			c	c
UserView	X	c	cu	cu	cu	cu	cu	cu			cu	cu			c	cu
UserCreateTechUser	X	c
UserModifyTechUser	X	c
UserDeleteTechUser	X	c
UserArchiveTechUser	X	c

Fine-grained permissions of nevisIDM roles

A nevisIDM role is mapped to a set of elementary rights, also called "elementary permissions". These rights determine the operations a user can execute.

Fine-grained permissions are an extension of the elementary rights and can be used to restrict an elementary right to specific attributes. For example, we can restrict the Helpdesk role to be able to modify only the user state but no other user attributes.

If no fine-grained permissions are defined, the user will be authorized for all attributes, without any restrictions. The nevisIDM roles do not contain any default fine-grained permissions; their definition is optional.

Configuration of fine-grained permissions

The fine-grained permissions are defined in the "rolesMapping.properties" configuration file. They have to be set in the format "ElementaryRight.Attribute", where "ElementaryRight" is the name of an elementary right, and "Attribute" is the name of the attribute to which we want to restrict the elementary right.

For example, if we want to restrict a nevisIDM role to be able to modify only the state of a user, the fine-grained permission "AccessControl.UserModify.state" has to be added to the configuration file.

*If a fine-grained permission for an elementary right is defined in the role configuration, the elementary right itself should not be listed. If a role configuration contains fine-grained permissions and the elementary right, the fine-grained permissions will be ignored.

For example: If the fine-grained permission "AccessControl.UserModify.state" is defined in the role configuration, the "AccessControl.UserModify" elementary right should not be listed. Otherwise, the fine-grained permission will be ignored, and the user modification will not be restricted to the state attribute.

Notes:

• Fine-grained permissions are supported only for the "AccessControl.UserView" and "AccessControl.UserModify" elementary rights and for the following user attributes:

  loginId	mobile	template_collection
  extid	addressline1	languageId
  client	addressline2	remarks
  state	postalcode	validFrom
  firstName	city	validTo
  name	country	isTechnicalUser
  title	street	stateChangedDate
  sex	houseNumber	stateChangeReasonCd
  birthDate	dwellingNumbe	stateChangeDetail
  email	postOfficeBoxText	lastLogin
  telephone	postOfficeBoxNumber	lastFailure
  telefax	locality

• Fine-grained permissions for properties with scope "onUserGlobal" can also be defined in the format "ElementaryRight.prop.PropertyName". For example: We have a property, called "userProperty" with scope "onUserGlobal" and we want to restrict the "AccessControl.UserModify" elementary right to this property. The rolesMapping.properties has to be extended with the "AccessControl.UserModify.prop.userProperty" fine-grained permission.

• Fine-grained permissions are not supported for technical attributes like "ctlCreUid", "ctlCreDat", "ctlCreUid", "ctlModDat", "ctlModUid" and "ctlTcn".

Fine-grained permissions on the nevisIDM admin GUI

On the "User administration" view, the values of the attributes will be visible and modifiable depending on the fine-grained permissions.

Only the values of the attributes for which we have fine-grained permissions on the "AccessControl.UserView" elementary right will be visible, and only the attributes for which we have fine-grained permissions on the "AccessControl.UserModify" elementary right will be modifiable.

The fine-grained permissions are applied neither on the user search and user history views nor on the result of the user export and report.

Fine-grained permissions in the web services

The fine-grained permissions are also applied on the user-related web service operations. The result of a query operation will contain only the attributes for which we have fine-grained permissions on the "AccessControl.UserView" elementary right. The other attributes will not be returned by the query operations.

Also, only the attributes for which we have fine-grained permissions on the "AccessControl.UserModify" elementary right can be modified. Trying to modify an attribute the caller user does not have permission for will result in an exception with the error code "errors.insufficientFineGrainedRights".

The fine-grained permissions are applied to the following web service operations: queryUsers, getUsersByLoginIds, getUsersByExtIds, getUsersByProfileExtIds, getAuthorizers, updateUser.

The fine-grained permissions are not applied to the getHistoryOfUser web service operation.

Configuration example

Modify the Helpdesk nevisIDM role to be able to view all user attributes, but be able to modify only the state attribute.

By default, the Helpdesk role contains the "AccessControl.UserView" and "AccessControl.UserModify" elementary rights. Since the Helpdesk role should be able to view all user attributes, no fine-grained permission has to be defined for the "AccessControl.UserView" elementary right. We only have to define fine-grained permission for the "AccessControl.UserModify" elementary permission.

To change the Helpdesk role, the following steps have to be taken:

• Open the "rolesMapping.properties" configuration file.
• Remove the "AccessControl.UserModify" elementary right from the configuration of the Helpdesk role.
• Add the "AccessControl.UserModify.state" fine-grained permission to the configuration of the Helpdesk role.
• Restart nevisIDM.

Magic roles and special users

Magic roles

Some roles are called "magic roles". nevisIDM knows their names and handles them in a different way:

• Role "SelfAdmin": Data room authorization is only valid for objects of the acting user.
• Role "TechUser": Role without any privileges in nevisIDM. Used for checking in a SecurityRoleFilter in nevisProxy (like roles of other applications)

Special users

There is one particular exception from the roles above, which only applies to the user "nevisauth". This technical user is part of and protected by the nevisIDM ref-data and represents the component nevisAuth. If there are nevisIDM AuthStates configured in nevisAuth, these states will call nevisIDM web services with a secToken issued for the user "nevisauth". In nevisIDM, all authorization checks are disabled for this user to increase performance as an authentication back end of nevisAuth.

Privilege escalation of nevisIDM roles

To prevent users such as Helpdesk or UserAdmin from being able to change the password of a user with the role Root and thereby take the root user's privileges, restrictions are required. These restrictions define which role is required to edit another role. The definition of privilege escalation can be found in the configuration file "authorizationConfig.properties" ).

The figure below shows the role hierarchy. The permission to administrate a user is related to editing the user object itself as well as the attached profiles and credentials. The "can edit"-relation shown in the figure is transitive and is interpreted as follows:

• Editing of a profile P is allowed if the actor's nevisIDM roles allow to edit all roles of the profile P.
• Editing a user and his credentials is allowed if all profiles of the user can be edited.

As shown in the diagram, Helpdesk is able to assume control over the accounts of (Main) AppOwner and/or UserAdmin because Helpdesk users can edit credentials. Helpdesk is therefore a powerful role, and users with this role should be instructed accordingly.

The described restrictions do not apply to the assignment of roles. An AppOwner, for example, can assign/revoke applications to/from all users (even to/from a root user). Only roles that one is allowed to assign can be revoked. Due to this rule, it is not possible to revoke the roles AppAdmin or Helpdesk unless that user has the role root.