Skip to main content
Version: 2.75.x.x LTS

Concept Description and Technical Architecture

This chapter provides a high-level feature-oriented view of nevisIDM and the context in which it is used with the Nevis Security Suite.

What is it about

nevisIDM manages the users, roles and permissions of your business applications in a centralized way. This central control and administration of data makes your system more secure and reduces costs. It also paves the way for a company-wide single sign-on. Together with the support for a broad range of user credentials, the implementation of strong authentication mechanisms is possible.

nevisIDM overview

Identity Management (IDM) describes the management of in Together with nevisProxy and nevisAuth, nevisIDM enables the implementation of a highly sophisticated, state-of-the-art identity and access management system. Within this system, nevisProxy builds one single point of access to your business applications in the back end and as such controls all incoming and outgoing HTTP traffic. nevisAuth takes care of the user identification and authentication. This is where nevisIDM comes in: it offers all the information that nevisAuth needs to identify and authenticate the user. This also includes user authorization: assigning users the correct permissions and roles they need to be able to work with the desired application. nevisIDM contains all processes and supporting tools required to manage your application and user data, including roles and permissions. The product can deal with a wide range of user credentials, such as (one-time) passwords, certificates, URL tickets, security questions, mTAN or FIDO. This makes it possible to use strong authentication mechanisms for your business applications.

Web GUI​

The web user interface (web GUI) of nevisIDM offers an administration interface to the identity management of the Nevis Security Suite. You can manage the following elements via the web GUI:

  • Users
  • Organizational units
  • Applications
  • User credentials (authentication information)
  • Roles and properties (authorization information)
  • Enterprise roles
  • Clients
  • Credential policies and mail templates

nevisIDM manages the access to these elements through administration roles. These roles use the same technique as nevisIDM provides for third-party applications protected by the Nevis framework. The authorization schema of nevisIDM is described in Security. The web GUI can be customized by changing the colors or replacing the logo, to match the corporate design of the organization working with nevisIDM. Find detailed information in Facing of web GUI design.

REST interface​

The REST interface – like the SOAP interface – provides a well-defined interface for exchanging information with third-party applications. It can be used for OpenID:Connect federation, resource-oriented access to nevisIDM data and to query users with full-text queries. For a detailed description of the REST interface see the REST API documentation or see REST Interface.

SOAP interface​

The SOAP interface offers a well-defined interface for exchanging information with third-party applications. It can be used for various kinds of imports and exports, as well as for initial data migration to nevisIDM. For a detailed description of the functions and access mechanisms of the SOAP interface, see in SOAP Interface.

History Viewer​

The History Viewer shows how data has changed over time. nevisIDM stores events such as Insert, Update or Delete within versioning tables, together with the timestamp and the actor of the event (that is, the user that performed the action). The History Viewer summarizes these events.

Additional features

  • Remote administration via the web interface.
  • Implementation of your authorization concept via user associations with profiles and roles.
  • Implementation of complex processes by means of a workflow engine (nevisWorkflow).
  • Bulk import of user data via Excel files.
  • Powerful output management (mail, SMS, letters).
  • Facilitates auditability with versioned storage of documents and security relevant events. All access rights are fully auditable at any time.
  • Event-based provisioning to third party systems.
  • File-based audit logging, for permanent recording of security related events.

Technical architecture

The next figure shows the architecture of the nevisIDM application. It consists of the following architectural elements or layers:

  • Client layer The client layer is the interface for interaction between the "outside world" and the nevisIDM application. For more details, see further below.
  • Business layer The business layer implements the nevisIDM business logic. It also provides several modules (or hooks) to implement different functionality. For more details, see further below.
  • Persistence nevisIDM supports Oracle and MariaDB databases for persistency. The nevisIDM package comes with a set of SQL scripts that allow the creation and initialization of the nevisIDM database. Every data change is versioned to provide a full audit trail.
nevisIDM technical architecture

Client layer​

The client layer is the interface for interaction between the "outside world" and the nevisIDM application. It includes the nevisIDM web user interface (web GUI) as well as the Login, Admin and SelfAdmin services (see the previous figure). The access to the web application happens through a secure reverse proxy (nevisProxy in combination with nevisAuth). The access to the Login, Admin and SelfAdmin services will take place either through nevisProxy/nevisAuth, or directly via calls from third-party components (e.g., your business applications).

The nevisIDM web application or web GUI facilitates the performance of administrative tasks, such as the administration of users, applications or authorizations. It also allows you to configure policies and mail templates for each of your tenants or mandates ("clients" in nevisIDM language).

Together, the Login, Admin and Self-Admin services build the SOAP web service facade. The Login service is called by nevisProxy/nevisAuth during the process of authenticating a certain user who wants to access your (Nevis-protected) application(s). The Admin service is called either by nevisDataPorter, Nevis' provisioning engine, or by your application(s). The Self-Admin service is used by users of your application(s) that want to perform certain administrative tasks, such as to reset their application passwords or to view their user details. The Login, Admin and Self-Admin services use the same business services as the web GUI/application. Also, authentication and authorization are implemented in the same way as in the web application.

Business layer​

The business core layer, also "business layer", provides a set of business services that are used by the web application and the web service front ends (the Login, Admin and Self-Admin services). nevisAuth also uses the business layer, to access the user data required during the login process (including write access, e.g., to set the login failure counter). The business layer:

  • Handles and organizes access to all entity objects within the nevisIDM data model.
  • Implements the data room authorization to ensure that administrators and users can only access, read or modify those entities they are entitled to.
  • Manages applications and roles as well as units.

The business services use a set of generic modules for certain tasks (see the previous figure). For example, the verification of a policy is performed by one module whereas another module is responsible for auditing. The modules generally support a manager-provider concept. This permits configurative integration of additional implementations, e.g., adding a new export provider. The following modules are available:

  • Event and scheduler module The event and scheduler module handles events by using a persistent queue. Periodic tasks may also be triggered by this module.
  • Provisioning module The provisioning module provides the provisioning interface with Nevis' provisioning engine nevisDataPorter.
  • Printing module The printing module provides the printing functionality necessary to execute all printing jobs.
  • Mail module The mail module provides the mailing functionality. It composes the e-mails based on the templates you create for this purpose. The module also takes care that the e-mails are sent to the correct receivers of the mails.
  • Policy module The policy module is a generic validation module. It manages and enforces policies and performs, among others, password policy checks.
  • Audit module The audit module provides the auditing functionality necessary to audit all transactions performed by nevisIDM. It also supports the logging of security-relevant events with several different providers.
  • Batch module The batch module enables the execution of batch jobs.

Data model

This chapter gives a high-level overview of the nevisIDM data model. You find a detailed explanation of . The nevisIDM data model consists of fixed core entities, such as users, units, applications and roles, and their attributes, as well as customizable properties. Besides these entities, the data model also involves the relations between those entities.

Core model​

The core data model is a static model based on practical experiences from many customers. It shows how nevisIDM understands the world of identity management abstracted from the real world. This part of the nevisIDM data model cannot be changed. It consists of fix entities (users, units, etc.) and their attributes, which are given. The entities' attributes have been selected because they represent a general property or characteristic of an entity that is used by most of our customers. E.g., the entity User has, among others, the core attributes First name and Last name. The core model can be

  • The core entities and their relations.
  • The client as a very specific part of the core model. Clients (also known as tenants) allow to completely separate populations of users, units, etc.
  • The authorization relations, that is, the

Customizable property extensions of the data model​

For the data model to represent a company's reality correctly, every customer needs his own, specific attributes. The nevisIDM data model allows creating this kind of customizable attributes, which we call "properties". Properties are a powerful and simple way to adapt the nevisIDM data model to the specific needs of your company. The next figure shows the User, Credential, Profile and Application entities with core attributes and custom properties as well as the connections between these entities.

nevisIDM data model

Data rooms​

From an administrative perspective, the nevisIDM data model can be broken down into four administrative sections, or, in nevisIDM terminology, four data rooms:

  • User and authentication administration (users and credentials)
  • Application administration (applications and roles)
  • Authorization administration (profiles, units and authorizations)
  • Enterprise administration (enterprise roles)

The administrative data rooms facilitate the

Data lifetime periods (valid from - valid to)​

It is possible to define the lifetime periods of information stored in nevisIDM. This allows for a more detailed control over the length of time a nevisIDM user possesses a certain role or is able to log in. Among others, lifetime periods can be used to model subscriptions or to preschedule the creation of users. Lifetime periods are available on:

  • Units, to check with a profile's direct parent unit whether the profile has an active lifetime period. This check takes place upon login.
  • User and profiles, to control if the user and/or profile is allowed to log in.
  • Authorizations and enterprise authorizations, making it possible to give access to a role for a period of time only.
  • Credentials, to control whether the credential is valid for login.

All data lifetime period checks and calculations are based on the login time of the user - and not forcefully checked again after a successful login.

Credentials

Credentials play an important role in preventing unauthorized users from accessing a system. A credential is a means by which a user can authenticate himself during the login process. "Credentials" is an entity of the core nevisIDM data model.

nevisIDM supports various types of credentials, e.g., password, certificate, Kerberos, etc., which belong to one of the following two groups: direct authentication credentials or external credentials. The information for direct authentication credentials is completely stored in nevisIDM. Therefore, nevisIDM decides about authentication success/failure autonomously without contacting any other system. In case of external credentials, the authentication information is not stored in nevisIDM but in another system, e.g., an Active Directory.

The following credentials are direct authentication credentials:

  • Password
  • Ticket
  • Temporary strong password
  • OTP
  • Vasco Digipass token
  • Certificate
  • SuisseID
  • PUK
  • URL ticket
  • Device password
  • Context password
  • Security question
  • OATH

These credentials belong to the group of external credentials:

  • Kerberos
  • SecurID
  • Safeword
  • mTAN
  • Generic credential
  • Mobile signature
  • SAML federation

For more detailed information about credentials, see Credentials.

Browser compatibility

For an overview of all supported web browsers, see the Nevis flyer "Nevis Security Suite – Browser Support". You find this flyer in the AdNovum Customer Zone, under "Nevis Documentation", or on the Nevis Publications Platform. If you do not have access to one of these platforms, contact the Nevis team at AdNovum.

The nevisIDM web GUI does not support multi-tab browsing. Therefore, we do not recommend opening the nevisIDM web GUI in multiple browser tabs.