Document toolboxDocument toolbox

Smart ID deployment recommendations

This article includes updates for Smart ID 23.04.

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.

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.

Database recommendations

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.

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.

Supported databases and browsers

Database compatibility

These databases are supported by all Smart ID components:

  • MS SQL 2019

  • PostgreSQL 11, 12 

  • MS Azure SQL

  • Oracle 19c

Identity Manager supports PostgreSQL 14 and 15.

 

Browser support

The following browsers are supported by all Smart ID components::

  • Mozilla Firefox with any latest version

  • Google Chrome with any latest version

  • Edge Chromium with any latest version

  • Safari 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:





Copyright 2024 Technology Nexus Secured Business Solutions AB. All rights reserved.
Contact Nexus | https://www.nexusgroup.com | Disclaimer | Terms & Conditions