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 is 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 are 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 is ignored, and the user modification is not 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
• extid
• client
• state
• firstName
• name
• title
• sex
• birthDate
• email
• telephone
• telefax
• mobile
• addressline1
• addressline2
• postalcode
• city
• country
• street
• houseNumber
• dwellingNumber
• postOfficeBoxText
• postOfficeBoxNumber
• locality
• template_collection
• languageId
• remarks
• validFrom
• validTo
• isTechnicalUser
• stateChangedDate
• stateChangeReasonCd
• stateChangeDetail
• lastLogin
• lastFailure

• 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 are 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 are visible, and only the attributes for which we have fine-grained permissions on the AccessControl.UserModify elementary right are 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 contain only the attributes for which we have fine-grained permissions on the AccessControl.UserView elementary right. The other attributes are not 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 results 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.

Credential-type specific permissions of nevisIDM roles

Credential-type specific permissions represent an extension of elementary rights, akin to fine-grained permissions. They serve to limit an elementary right to specific credential types. For instance, the HelpDesk role can be restricted to creating/modifying/viewing only PASSWORD type credentials, excluding any other types.

If no credential-type specific permissions are defined, the user is authorized for all credential types, without any restrictions. The nevisIDM roles do not contain any default credential-type specific permissions; their definition is optional.

Configuration of credential-type specific permissions

The credential-type specific permissions are defined in the rolesMapping.properties configuration file. They have to be set in the format ElementaryRight.CredentialType, where ElementaryRight is the name of an elementary right, and CredentialType is the name of the credential type 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 KERBEROS type credentials, the credential-type specific permission AccessControl.CredentialModify.KERBEROS has to be added to the configuration file.

If a credential-type specific permission for an elementary right is defined in the role configuration, the elementary right itself should not be listed. If a role configuration contains credential-type specific permissions and the elementary right, the credential-type specific permissions are ignored.

For example: If the credential-type specific permission AccessControl.CredentialModify.KERBEROS is defined in the role configuration, the AccessControl.CredentialModify elementary right should not be listed. Otherwise, the credential-type specific permission are ignored, and the credential modification is not restricted to the type of the credential.

Notes:

• The following elementary permissions can be extended with credential-type specific permissions:

  • AccessControl.CredentialCreate
  • AccessControl.CredentialModify
  • AccessControl.CredentialView
  • AccessControl.CredentialDelete
  • AccessControl.CredentialChangeState
  • AccessControl.CredentialPdfView
  • AccessControl.CredentialViewPlainValue
  • AccessControl.CredentialSearch

• The format of the credential-type specific permissions is case-insensitive. Furthermore, the credential type can be specified either by its name or by its ID. For example, the following credential-type specific permissions are equivalent:

  • AccessControl.CredentialModify.KERBEROS
  • AccessControl.CredentialModify.10
  • AccessControl.CredentialModify.Kerberos

The supported credential types can be found listed below.

• Credential Password:
  • ID: 1
  • Name: PASSWORD

• Credential Certificate:
  • ID: 2
  • Name: CERTIFICATE

• Credential SecurID:
  • ID: 3
  • NAME: SECURID

• Credential Ticket:
  • ID: 4
  • NAME: TICKET

• Credential SafewordUser:
  • ID: 5
  • NAME: SAFEWORDUSER

• Credential OTP:
  • ID: 6
  • NAME: OTP

• Credential TempStrongPassword:
  • ID: 8
  • NAME: TEMPSTRONGPASSWORD

• Credential Generic:
  • ID: 9
  • NAME: GENERIC

• Credential Kerberos:
  • ID: 10
  • NAME: KERBEROS

• Credential MTAN:
  • ID: 11
  • NAME: MTAN

• Credential Vasco:
  • ID: 12
  • NAME: VASCO

• Credential PUK:
  • ID: 13
  • NAME: PUK

• Credential UrlTicket:
  • ID: 14
  • NAME: URLTICKET

• Credential DevicePassword:
  • ID: 15
  • NAME: DEVICEPASSWORD

• Credential MobileSignature:
  • ID: 16
  • NAME: MOBILESIGNATURE

• Credential SamlFederation:
  • ID: 17
  • NAME: SAMLFEDERATION

• Credential SecurityQuestions:
  • ID: 18
  • NAME: SECURITYQUESTIONS

• Credential ContextPassword:
  • ID: 19
  • NAME: CONTEXTPASSWORD

• Credential Oath:
  • ID: 20
  • NAME: OATH

• Credential FidoUaf:
  • ID: 21
  • NAME: FIDO_UAF

• Credential RecoveryCode:
  • ID: 22
  • NAME: RECOVERY_CODE

• Credential Fido2:
  • ID: 23
  • NAME: FIDO2

Configuration example

Modify the Helpdesk nevisIDM role to be able to view all types of credentials, but be able to modify only the password types.

By default, the Helpdesk role contains the AccessControl.CredentialView and AccessControl.CredentialModify elementary rights. Since the Helpdesk role should be able to view all types of credentials, no credential-type specific permission has to be defined for the AccessControl.CredentialView elementary right. We only have to define credential-type specific permission for the AccessControl.CredentialModify elementary permission.

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

• Open the rolesMapping.properties configuration file.
• Remove the AccessControl.CredentialModify elementary right from the configuration of the Helpdesk role.
• Add the AccessControl.CredentialModify.password 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 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.