Smart ID deployment recommendations

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?

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.

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.

The minimum database requirements can be found on each database vendor's page for setting up an appropriate database. These requirements apply to a standard shipment of Smart ID

The database server should be run in default configuration. Deviations from the standard configuration need to be aligned with your Nexus partner or Nexus project team.

There might be some specifics to each Smart ID component, which can be found via the links in the "More on requirements and interoperability" section.

The correct server sizing or capacity depends on the use cases, user load and, for example, automated import and export processes and should therefore be defined together with your Nexus partner or Nexus project team.

Performance tuning, adding indexes and statistics need to be aligned with your Nexus partner or Nexus project team, to avoid, for example, later update issues. If you have highly customized processes and use cases, the data amount in the database depends on the complexity of the processes and how often these trigger the persistence in its runtime (number of save tasks, state change tasks, user forms, etc.) multiplied by the number of users using these processes. In this case your Nexus partner or Nexus project team is recommended to measure the database growth on their test systems, in order to give you the best possible indication.