Info |
---|
This article is valid for Smart ID 24.R1 and later. |
THIS IS A WORK IN PROGRESS!
Smart ID Identity Manager offers support for HSM (Hardware Security Model) for several use cases:
...
Identity Manager requires a native bridge DLL for the access to the HSM's PKCS#11 library, jpkcs11.dll/libjpkcs11.so
The library is provided with your Identity Manager package or on request.
The library exists as 32bit and 64bit version. The bit version must correspond to the JRE used with the Identity Manager server.
To be accessed, the library needs to be available in the PATH environment variable.
Create a new folder for it and add the folder to the PATH
OR
Copy it to your C:\Windows\System32 folder (in case you are using the 64bit DLL on a 64bit system with 64bit JRE - the same with a pure 32bit solution).
Configure
...
engineSignEncryptConfig.xml
...
/ signencrypt.xml
Do the Identity Manager HSM configuration in the file engineSignEncryptengineSignEncryptConfig.xml in the WEB-INF/classes folder for each of the the relevant Identity Manager clients, i.e. IDM Admin and IDM Operator (in case of Docker deployment, the file docker/compose/identitymanager/config/signencrypt.xml needs to be edited instead).
Note |
---|
All Identity Manager clients that use the same database, must have the same engineSignEncrypt.xml configuration.keys and certificates configured in the XML. |
The following example is an extract showing four use cases configured for HSM (see also Sign and encrypt engine in Identity Manager for further use cases that can be configured in engineSignEncrypt.xml).
descriptor
EncryptedFields
is used for handling secrets with the Identity Manager SecretFieldStoredescriptor
ConfigZipSigner
is used for signing and verifying Identity Manager configuration zip filesdescriptor
ObjectHistorySigner
is used for signing and verifying the Identity Manager Object Historydescriptor
SignEmailDescriptor
is used for signing S/MIME mails with MailService tasks
...
To avoid this, you have these options:
Deploy each Identity Manager webapp on its own dedicated Tomcat instance (Docker deployments always work like this).
OR
Remove all CMSDK JARs and all BouncyCastle JARs from all webapps' tomcat\<webapp>\WEB-INF\lib folders and place them in tomcat\libs instead (this ensures those JARs are served from the Tomcat common classloader for all webapps).
CMSDK JARs:
cmcommon*.jar
cmsdk-*.jar
common-*.jar
BouncyCastle JARs:
bcmail-*.jar
bcpgp-*.jar
bcpkix-*.jar
bcprov-*.jar (including bcprov-ext-*.jar)
Additional information
Expand | ||
---|---|---|
| ||