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

Architecture Overview

This chapter provides a high-level, feature-oriented view of the nevisMeta component and provides information about the context in which nevisMeta is used.


nevisMeta is designed to facilitate the setup of federation protocols within the Nevis framework. It offers the following features:

  • A central management point of metadata for setups of particular protocols. Each protocol is handled by a dedicated module.
  • All necessary information for participants of setups to fulfill roles as defined by the particular protocol. This information is provided in the form of XML or JSON documents that can be retrieved via REST services. The documents enable participants to configure themselves dynamically according to the description of the setup.
  • A REST interface that allows retrieving, creating, modifying and deleting setups and entities. The rest interface will return data at the time of the call or, if a date is provided, at a specific point in time, see the chapter REST API V2.
  • All modifications are dated: Any changes may be defined to take effect immediately or at any point in the future. Consumers of the nevisMeta REST service (typically participants in those same managed setups) receive instructions on how long to maximally cache the data they received. This enables coordinated changes of setup configuration between all interested participants without the need for explicit coordination communication or deployment windows, see the chapter "Entities and states.

Web console

The nevisMeta web console offers an easy-to-use administration interface for the module setups that are managed in nevisMeta, see the chapter Main screen. It offers the following functionalities:

  • creating new setups
  • adding new entities with module-specific types to a setup
  • editing general properties of the setup that affect all participants
  • editing and deleting entities
  • specifying the validity date for each modification

These functionalities are protected from unauthorized access.

For an overview of all supported web browsers, see the Nevis flyer Nevis Security Suite – Browser Support. You can 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 REST API provides a well-defined interface for exchanging information with participants of a setup and with other services. Because it is feature-complete, it can also be used to implement a custom, specialized front-end for managing nevisMeta functionality (e.g., custom configuration point). A detailed description of the REST API can be found in the chapter REST API V2.


nevisMeta offers persistence based on MariaDB or Couchbase.

  • Couchbase provides a NoSQL document store. The setup of Couchbase is described in Couchbase setup.
  • MariaDB is an SQL-based relational database. The setup of MariaDB is described in MariaDB setup.

Supported protocols

Currently, nevisMeta implements a module for OAuth 2.0. It supports the following protocols:

  • OAuth 2.0 [2]
  • OpenID Connect Core [3]

Deployment architecture

The following illustration shows nevisMeta in an abstract architecture:

  • Admin users have access directly to the nevisMeta web GUI, where they can edit data of setups and entities.
  • Custom Configuration Points may provide a tailored user interface, which allows a Protocol Specialist to interact with nevisMeta using the REST interface (note that such a service is not provided by nevisMeta but must be implemented separately).
  • Participant Services consume metadata from nevisMeta to configure themselves dynamically.
  • End-users interact with the Participant Services only (i.e., not directly with nevisMeta).

In the illustrated setup two nevisMeta instances are employed for high availability (failover) but the backup connections for the Participant Services and the Custom Configuration Point are omitted for clarity. The nevisMeta instances are backed by a Couchbase cluster of two nodes.