Migrate from SmartACT to Identity Manager
This article describes how to migrate from SmartACT to Smart ID Identity Manager.
This is a summary of what must be in place before the migration starts. More information is found in the article.
Java 8 Runtime is installed
JRE_HOME is set as environmental variable
java-security-policy-fix is recorded
Databases are correctly registered in database.properties
Run Data Encryption Certificate is provided and configured in encryption-config.xml
Personalization is done correctly in migrate_persons.properties
Configuration for cards/tokens is correct in migrate_cards.properties
Certificates configuration is correct in migrate_certificates.properties (PKI only Card management)
Smart ID configurations (for example, Base, Physical ID, DIgital ID) in the latest version are available
Step-by-step instruction
Preparation
Install the current version of Java Runtime Environment (JRE).
Set JRE_HOME to the installation directory of java jre
(for example: C:\Program Files\Java\jre1.8.0_161\bin)Import the java-security-policy-fix for the installed Java version. The jce-policy-8.zip is provided with the migration package.
Unpack the migration package of delivery in a directory of your choice.
Go to the specified migration directory.
In the file database.properties specify the attributes HOST_NAME, DB_PORT, DB_NAME, USER_NAME and USER_PASSWORD for SmartACT and Identity Manager. The properties inside database.properties match those, described in PRIME installation.
SmartACT database
### SmartACT Database smartAct.jdbcUrl=jdbc:sqlserver://<HOST_NAME>:<DB_PORT>;databaseName=<DB_NAME>;AUTO_SERVER=TRUE #smartAct.jdbcUrl=jdbc:sqlserver://<HOST_NAME>:<DB_PORT>;databaseName=<DB_NAME>;instance=<INSTANCE_NAME>;AUTO_SERVER=TRUE - verwendet für SQLEXPRESS Datenbank-Server smartAct.user=<USER_NAME> smartAct.password=<USER_PASSWORD>Identity Manager database
### PRIME Database prime.jdbcUrl=jdbc:sqlserver://<HOST_NAME>:<DB_PORT>;databaseName=<DB_NAME>;AUTO_SERVER=TRUE #prime.jdbcUrl=jdbc:sqlserver://<HOST_NAME>:<DB_PORT>;instance=<INSTANCE_NAME>;databaseName=<DB_NAME>;AUTO_SERVER=TRUE - verwendet für SQLEXPRESS Datenbank-Server prime.user=<USER_NAME> prime.password=<USER_PASSWORD> ...
You must have read/write rights of the SQL users on the databases.
Make sure that the certificate for encrypting run data in SmartACT (idexpertcert02.p12) is stored in the directory config. The migration tools contains this certificate, if it is not supplied by you.
Open the file encryption-config.xml and check if the value of the attribute pin under the key idexpertcert02 is correct, otherwise set the value:
encryption-config.xml
... <keys> <key name="idexpertcert02"> <type name="pkcs12" locationValue="config/idexpertcert02.p12" pin="XXXX"/> </key> </keys> ...
Configure migration - general
The configuration is done in the migrate_general.properties file, which is structured as follows.
Atribute | Value | Importance |
|---|
Atribute | Value | Importance |
|---|---|---|
abortOnError | true/false |
|
printReport | true/false |
|
printDetailReport | true/false |
|
prime.username |
| Name of the administrator of the respective tenant. |
prime.userpassword |
| The administrator's password. |
prime.tenantId |
| Tenant ID |
Configure migration - persons
The configuration is done in the migrate_persons.properties file, which is structured as follows.
These are examples of person statuses:
Example: Person status in SmartACT
...
smartact.person.state.active=1
smartact.person.state.inactive=2
smartact.person.states=${smartact.person.state.active},
${smartact.person.state.inactive}
Example: Person status in Identity Manager
...
prime.person.state.active=active
prime.person.state.inactive=inactive
prime.person.states=${prime.person.state.active}, ${prime.person.state.inactive}
...
Make sure that the number of states between SmartACT (attribute smartact.person.states) and Identity Manager (attribute prime.person.states) are always the same.
For the attribute smartact.masterdata.template.ids, enter one or more comma-separated Master data template IDs if you only want to migrate specific master data templates.
...
prime.person.coretemplate.names=BaseCtEmployee
...
Make sure that the number of master data types between SmartACT (smartact.masterdata.template.ids) and Identity Manager (prime.person.coretemplate.names) are the same.
Every person from SmartACT is assigned the role BaseRoleSelfServiceUser as part of the migration to Identity Manager, so access via USSP is possible. This can be customized in migrate_persons.properties under the parameter prime.person.roles.added.
...
prime.person.roles.added=BaseRoleSelfServiceUser,<RoleNameIdM>,...
prime.person.roles.deleted=<RoleNameIdM>,...
...
The roles are specified as a comma-separated list. These are applied to all person objects during the migration process.
The mapping of the data fields between Identity Manager and SmartACT is configured in the file spring\migrate-persons-batch_jobs-beans.xml. The assignment must be adjusted according to the use of the data fields in the following area:
<util:map id="personFieldMapping">
<!-- <entry key="SmartAct_ColumnName"
value="Prime_CoreTemplate_FieldName"/> -->
<!-- migration specific mapping -->
<entry key="MigrationId" value="MigrationId"/>
<entry key="MD_MDTID" value="Meta_CoreTemplateName"/>
....
</util:map>
In Identity Manager, new data pool fields might have to be created as additional fields. At least, MigrationId should be added as a numeric field, as this is not part of the standard Identity Manager modules.
The mapping of the persons is preset as follows:
SmartACT field | Identity Manager field | Comment |
|---|
SmartACT field | Identity Manager field | Comment |
|---|---|---|
COMPANY | Company |
|
DEPARTMENT | Department |
|
| ||
FIRSTNAME | FirstName |
|
INFOBIGTEXT0 | UPN |
|
LASTNAME | LastName |
|
MD_CREATEDATE | CreationDate |
|
MD_DATE | ModificationDate |
|
MD_ID | MigrationId | Alias and internal ID of the Master record in SmartACT |
MD_MDTID | TenantId Meta_CoreTemplateName_ BaseDpEmployee is set via | Alias and internal ID of the MDT in SmartACT |
MD_REASON | Meta_CoreObjectStateChangeReason_BaseDpEmployee |
|
MD_STATE | Meta_CoreObjectState_ BaseDpEmployee | Status of the person in SmartACT (refer to Type conversion for the person) 1: Active 3: Deleted |
For this, the MigrationId field is used, which is already used in SmartACT as uniqueness criterion.
Field | Conversion rule | Mapping used |
|---|
Field | Conversion rule | Mapping used |
|---|---|---|
MasterdataId | BIGDECIMAL_TO_LONG |
|
Meta_CoreObjectState | NUMBER_TO_STRING_CONDITIONAL | 1 > "registered" |
Configure migration - cards
The configuration is done in the migrate_cards.properties file, which is structured as follows.
...
smartact.card.field.PIN=PIN
smartact.card.field.PUK=PUK
smartact.card.field.CARD_CRKEY=CARD_CRKEY
smartact.card.encrypted.fields=${smartact.card.field.PIN}, ${smartact.card.field.PUK}, ${smartact.card.field.CARD_CRKEY}
...
All encrypted fields have to be available in this list otherwise the encrypted value which was created with SmartACT certificate will be saved in Identity Manager.
...
prime.card.field.PIN=PIN
prime.card.field.PUK=PUK
prime.card.field.CardManagerKey=CardManagerKey
prime.card.encrypted.fields=${prime.card.field.PIN}, ${prime.card.field.PUK}, ${prime.card.field.CardManagerKey}
...
A field which was not encrypted in SmartACT/ProACT can be encrypted in Identity Manager (subsequently encrypt).
Example:
...
smartact.card.state.issued=103
smartact.card.state.active=104
smartact.card.state.inactive=105
smartact.card.state.locked=106
smartact.card.states=${smartact.card.state.active}, ${smartact.card.state.inactive}, ${smartact.card.state.locked},${smartact.card.state.issued}
...
...
prime.card.state.issued=issued
prime.card.state.active=active
prime.card.state.inactive=inactive
prime.card.state.locked=locked
prime.card.states=${prime.card.state.active}, ${prime.card.state.inactive},
${prime.card.state.locked},${prime.card.state.issued}
Make sure that the number of status between SmartACT (attribute smartact.card.states) and Identity Manager (attribute prime.card.states) are the same.
Example:
...
smartact.card.template.ids = 3320,3321,3322, ...
...
Enter one or more card template IDs separated by commas. Enter all card types that you shall use.
...
prime.card.coretemplate.names = MyCtEmployeeCard, MyCtAdminCard, MyCtEmployeeCard
...
Mapping of card fields between Identity Manager and SmartACT is configured in the spring\migrate-cards-batch_jobs-beans.xml file.
The assignment must be adjusted according to the use of the data fields in the following area:
<util:map id="cardFieldMapping">
<!-- <entry key="SmartAct_ColumnName"
value="Prime_CoreTemplate_FieldName"/> -->
<!-- migration specific mapping -->
<entry key="MigrationId" value="MigrationId"/>
....
</util:map>
In Identity Manager, new data pool fields have to be created as additional fields. At least the MigrationId should be added as a numeric field, as this is not part of the standard Identity Manager modules.
The mapping of the cards is preset as follows:
SmartACT field | Identity Manager field | Comment |
|---|
SmartACT field | Identity Manager field | Comment |
|---|---|---|
CARD_NUMBER_TEXT | CardNumber |
|
CARD_PIN | PIN |
|
CARD_PUK | PUK |
|
CARDOS_CHIP_ID | ICCSN |
|
CRD_CTID | Meta_CoreTemplateName_PcmDpEmployeeCard | Internal ID of the master data template in SmartACT, which is linked to the core template name by further mapping (see |
CRD_DATE | ModificationDate |
|
CRD_ID | MigrationId | Alias and internal ID of the card. |
CRD_MDID |
| Alias and internal ID that references the person's Data Pool field |
CRD_PERSDATE | CreationDate |
|
CRD_PERSFLAGS |
|
|
CRD_REQID |
|
|
CRD_STATE | Meta_CoreObjectState_PcmDpEmployeeCard | Status of the card in SmartACT: |
CRD_TIMESTAMP |
|
|
DEPARTMENT | Department |
|
| ||
FIRSTNAME | FirstName |
|
INFOBIGTEXT0 |
|
|
UPN |
|
|
LASTNAME | LastName |
|
The field MigrationId is used, which is already used in SmartACT as uniqueness criterion.
Status SmartACT | Value SmartACT | Mapping in Identity Manager |
|---|
Status SmartACT | Value SmartACT | Mapping in Identity Manager |
|---|---|---|
Card is personalized | 100 | None/not accepted |
Card has been personalized | 101 | None/not accepted |
Card has been personalized and confirmed | 102 | None/not accepted |
Card was issued | 103 | Issued |
Card is active | 104 | Active |
Card is temporarily inactive | 105 | Inactive |
Card is permanently blocked | 106 | Locked |
Card was destroyed | 107 | None/not accepted |
Repetition of personalization | 108 | None/not accepted |
Card is reusable (for example, unallocated quota card) | 109 | None/not accepted |
Card is on a transportation or shipping route | 110 | None/not accepted |
Card was destroyed during personalization | 111 | None/not accepted |
Card is temporarily inactive - by user group 1 | 113 | None/not accepted |
Card is temporarily inactive - by user group 2 | 114 | None/not accepted |
Card is back again from a transportation or shipping route | 115 | None/not accepted |
Card is lost on a transportation or shipping route | 116 | None/not accepted |
Field | Conversion rule | Used mapping |
|---|
Field | Conversion rule | Used mapping |
|---|---|---|
TenantId | BIGDECIMAL_TO_STRING |
|
MasterdataId | BIGDECIMAL_TO_STRING |
|
MigrationId | BIGDECIMAL_TO_STRING |
|
Meta_CoreObjectState | NUMBER_TO_STRING_CONDITIONAL | 103 > "issued" |
The following relation is defined especially for the card (see also Relation between the objects)
Attribute |
|---|
Attribute |
|---|
Copyright 2024 Technology Nexus Secured Business Solutions AB. All rights reserved.
Contact Nexus | https://www.nexusgroup.com | Disclaimer | Terms & Conditions