Comment: This article is new for Smart ID Identity Manager 24.R1.
Remember to update the release version number before publishing externally.
David Banz there are some remaining questions in this article.
| Info |
|---|
| Info |
This article is new for Identity Manager 5.0.1. |
Descriptor overview
The engine’s descriptors are the following:
Descriptor | Description |
|---|---|
encryptedFields | Encryption and decryption of fields in the Identity Manager database |
configZipEncrypter | Encryption of the configuration files |
configZipSigner | Signing and validation of the configuration files |
objectHistorySigner | Signing and verification of the object history |
signEmailDescriptor | Signing of emails |
hermodDeviceEnc | Creation of device encryption certificates that are used in Smart ID messaging |
SelfServiceJWTSigner | Authentication of Smart ID Self-Service users to the Identity Manager backend |
ContentProviderJWSSigner | Creation of JWS signatures used for Smart ID messaging content provider API |
idopteAuthentication | Initial handshake with Idopte client-side middleware |
insideClientAuth | Authentication to the IN Groupe Inside Server |
att_* | Attestation for provisioning to Smart ID Mobile / Desktop Apps |
(arbitrary name) | Decryption of PIN blobs from pre-personalized smart-cards created with the Personal Desktop Client |
Each descriptor is described in detail in the sections below, including requirements how it shall be bootstrappeddescriptor is described in detail in the sections below, including requirements how it shall be bootstrapped.
Certain descriptors are used for optional features. If a certain feature (for example email signing) is not used in a given deployment, then you may configure the descriptor in question with a placeholder. Any PKCS#12 file containing a self-signed keypair will be sufficient in this case.
EncryptedFields
| Info |
|---|
Descriptor included in default configuration. Correct bootstrapping is required for productive use. Only dev- and test systems may use placeholders (for example created with bootstrap.zip package or the corresponding Docker docker container). |
Use
...
case
Encryption and decryption of fields in the Identity Manager database
...
| Info |
|---|
Descriptor included in default configuration. Correct bootstrapping may be required for productive use, depending on the use - case. Dev- and test systems may use placeholders (for example created with bootstrap.zip package or the corresponding Docker docker container). |
Use
...
case
Encryption of the configuration files
...
| Info |
|---|
Descriptor included in default configuration. Correct bootstrapping may be required for productive use, depending on the use - case. Dev- and test systems may use placeholders (for example created with bootstrap.zip package or the corresponding Docker docker container). |
Use
...
case
Signing and validation of the configuration files
...
| Info |
|---|
Descriptor included in default configuration. Correct bootstrapping may be required for productive use, depending on the use - case. Dev- and test systems may use placeholders (for example created with bootstrap.zip package or the corresponding Docker docker container). |
Use
...
case
Signing and verification of the object history
...
Placeholder allowed only if history verification is disabled (via
activitiHistoryCleanerJobTrigger.cronExpressionset to a date in the distant future. See List of Identity Manager system properties and Quartz CronTrigger tutorial for more information)Integrity of history signature would be as risk
Re-signing requires use of the batch_re-sign_history tool once the first history entry is created
If you plan on enabling it at a later date, it is recommended not to use a placeholder
Key requirements
...
| Info |
|---|
Descriptor included in default configuration. Correct bootstrapping may be required for productive use, depending on the use - case. Dev- and test systems may use placeholders (for example created with bootstrap.zip package or the corresponding Docker docker container). |
Use
...
case
Send signed e-mails emails from IDM
Required
When e-mail email signing is configured
Configured in the following application
...
Placeholders allowed only if email signing is not used
Email verification will fail if not issued by a trusted S/MIME CA
Integrity of e-mails emails sent by IDM may be at risk if placeholder key is used
...
Proper S/MIME certificate with configured IDM e-mail email sender address in DN's E field and/or SAN RFC-822 entry
If subject DN email field is absent, SAN extension must be critical
Note: broken Broken support for DN.E was is fixed in IDM 245.0.0.R1
must not be self-signed
Key usage:
If present, must be critical and at least either digitalSignature or nonRepudiationValidity:
Adhering to CAB-Forum requirements from https://cabforum.org/working-groups/smime/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods
...
| Info |
|---|
Descriptor included in default configuration. Bootstrapping required for technical reasons, but with relaxed security requirements compared to other use - cases. |
Use
...
case
Generate dummy certificate for transient key-pairs generated on a target device when provisioning Smart ID Mobile/Desktop App profiles (the certificates themselves are merely used as transport container for the key-usage parameter)
...
TODO: David Banz what should we add here? This info is missing.
Configured in the following application
...
| Info |
|---|
Descriptor included in default configuration. Correct bootstrapping is required for productive use. Only dev- and test systems may use placeholders (for example created with bootstrap.zip package or the corresponding Docker docker container). |
Use
...
case
Authentication of Smart ID Self-Service users to the Identity Manager backend
Required
TODO: David Banz what should we add here? This info is missing.-Service users to the Identity Manager backend
Configured in the following applications
...
| Info |
|---|
Descriptor included in default configuration. Correct bootstrapping may be required for productive use, depending on the use - case. Dev- and test systems may use placeholders (for example created with bootstrap.zip package or the corresponding Docker docker container). |
Use
...
case
Signing content for Visual ID provisioning to Smart ID Mobile App
...
TODO: David Banz what should we add here? This info is missing.
Configured in the following applications
Identity Manager Operator (See Set up visual ID layout in Identity Manager for more information.)
Storage
...
Certificate requirements
Must not be self-signed!
Key usage is not checked (recommended for informational purposes: set digitalSignature)
Issuing CA cert must be trusted by the app onto which to provision Visual IDs
Validity: at your discretion (make sure you do not forget to renew before the expiry date!), validity is checked on the SDK side
Versioning not needed (always uses the default (i.e. that is, highest) version)
Misc Attestation Key Descriptors (att_…)
...
| Info |
|---|
Descriptors included in default configuration. Correct bootstrapping may be required for productive use, depending on the use case. Replacement of the default certificates is optional. |
...
att_external-attestation-1 (mobile only)
att_external-attestation-2 (mobile only)
att_external-attestation-3 (mobile only)
att_external-attestation-4 (mobile only)
att_ATTESTATION (mobile+desktop, default)
Use
...
case
Verify Certification Signing Requests (CSR) from Smart ID Mobile/Smart ID Desktop App.
Optionally limit profile provisioning with Smart ID Mobile/Smart ID Desktop App to certain devices, for example company devices. This can be done by using Mobile/Desktop apps with custom private keys and configuring the corresponding public keys into IDM in Identity Manager (by default IDM Identity Manager includes certificates for the built-in keys of any Mobile and Desktop App installation)
...
TODO: David Banz what should we add here? This info is missing.
Configured in the following applications
...
Default certificates do not need to be changed, unless you want to limit profile provisioning to certain devices
No private keys is configured for IDMIdentity Manager, only each public key inside a certificate
...
| Info |
|---|
Descriptor not present by default, can be ignored unless the Idopte middleware is used for PKI card production. |
Use
...
case
Initial handshake with Idopte client-side middleware, see Encoding using Idopte middleware in Identity Manager
Required
TODO: David Banz what should we add here? This info is missing.in Identity Manager
Configured in the following application
...
Idopte webapp cert, issued by Idopte based on CSR for a customer-generated keypair
One customer-specific SAN URI (does not have to point to an existing website), e.g. for example https://idopte.customer.com (using hosts like localhost or 127.x.y.z is discouraged, as it severely restricts the maximum validity period of the certificate Idopte can issue)
Validity: defined by the Idopte CA
...
| Info |
|---|
Descriptor not present by default, can be ignored skipped unless the Idopte middleware is used for PKI card production. |
Use
...
case
Authenticate to the IN Groupe Inside Server, which performs certain cryptographic operations on behalf of IDM when using the Idopte middleware (see Encoding using Idopte middleware in Identity Manager)
Required
TODO: David Banz what should we add here? This info is missing.
Configured in the following applications
...
| Info |
|---|
Descriptors not present by default, can be ignored skipped unless pin-blobs from pre-personalized cards (using Personal Desktop Client/KGS) have to be decrypted. |
Descriptor names
Can be any descriptor listed in the pinBlobDecryptor.keyDescriptorNames property of system.properties (or its docker counterpart)
Use
...
case
Decrypting pin-blobs from pre-personalized cards to e.g. for example print pin letters for them (see Encodings using Personal Desktop Client middleware in Identity Manager (section "Read encrypted PINs")
Required
TODO: David Banz what should we add here? This info is missing.
Configured in the following applications
...