Nexus' software components have new names:

Nexus PRIME -> Smart ID Identity Manager
Nexus Certificate Manager -> Smart ID Certificate Manager
Nexus Hybrid Access Gateway -> Smart ID Digital Access component
Nexus Personal -> Smart ID clients

Go to Nexus homepage for overviews of Nexus' solutions, customer cases, news and more.

This article discusses the recommendations for Smart ID deployment.

Smart ID Certificate Manager and Nexus OCSP Responder are not included in this description. 

Deployment and sizing considerations

Smart ID is a highly flexible and scalable solution for small or large enterprises. Since Smart ID covers many different use cases and scenarios, the expected load on the different components and therefore the sizing and resource planning can differ significantly between customer cases.

The following list of considerations are guidelines to help our customers and partners to plan their specific setup.

Number of identities and concurrent users

The number of users is an indicator how many concurrent users we will have in the system. Card officers and registration officers typically work in the system multiple hours per day, while self-service users typically access it a couple of minutes at a time and quite rarely. There might be a peak of self-service users, for example when a lot of certificates expire at the same time or if an organizational change is done that require self-service interaction.

For authentication requests via the Digital Access Portal, in an enterprise scenario there is typically a peak in the morning and then a constant load during the day. This causes traffic on the Digital Access Portal and the Smart ID Messaging service.

A high number of concurrent users will cause load on the application servers. In that case, a load balancer setup with multiple nodes should be considered for the corresponding components.

Consider these questions about users and roles: 

  • How many users do you expect to be managed in the system, and for which use case? For example, employees, contractors, visitors, operators and administrators.
  • Which roles do these users have in the system, and how many users have each role? For example, end users that use Digital Access for authentication, Self-Service users, card officers, registration officers, administrators and helpdesk.
  • Do you plan to manage connected devices in the system? In that case, how many, and for which use case?

Background processes

Besides the use cases that are executed on the user front end, such as card enrollment, self-service tasks, and authentication requests, there are typically also processes running in the background. These background processes include daily synchronization with a user repository, for example Active Directory or HR system, automatic locking or revocation of credentials based on leaving dates, cleanup tasks, bulk requests for new credentials, or automatic certificate enrollment via protocols such as SCEP or ACME.

When scheduling these tasks, the following should be considered: 

  • If possible, avoid that multiple background processes are executed at the same time.
  • Depending on the use case, consider that background processes may consume a significant amount of processing time on the application server and the database.

Database sizing

Smart ID is typically the central platform to manage any kind of identities and corresponding credentials in an organization. Therefore, Smart ID has to collect, store and manage certain information about lots of different entities in the database. The number and type of entities to be stored can vary significantly depending on the customers scenarios. Therefore it is important to plan the sizing of the database properly.

Consider the following points:

  • Which type of information will be stored: users, requests, cards, certificates, entitlements, devices etc. And how many records of each type will be stored at the same time?
  • Logging and audit: Smart ID provides different kinds of audit information that is stored in the database, such as changes on any item that is managed, and protocols about authentication requests. Consider any background processes that might cause a large amount of changes per night, that end up in these protocols.
  • Binary data, such as photos or pdfs, might consume a lot of space in the database. Consider the size of the binary objects to be stored.

Supported databases, operating systems and browsers

Database compatibility

These databases are recommended and supported by all Smart ID components:

  • MS SQL 2019
  • Postgres 11, 12
  • MS Azure SQL

Browser support

The following browsers are supported:

  • Mozilla Firefox with any latest version
  • Google Chrome with any latest version
  • Edge Chromium with any latest version

More on requirements and interoperability

For more information on the full support of databases, operating systems, browsers, and so on, see the following articles:

This article is valid for Smart ID 21.04 and later.

Related information