App Connect

Steps to migrating from Basic Id to IBM Id

The Basic Id log mechanism isn't compliant and possesses a security risk, this log in mechanism doesn’t support 2 Factor Authentication.  IBM Id is an alternative to Basic Id. ACP redirects the user to IBM Id and it performs auth or 2FA and sometimes both. Once auth passes, IBM Id redirects the user back to the ACP dashboard.

The ACP team is planning to deprecate the Basic Id option and have only one log in mechanism. We strongly suggest migrating from Basic Id to IBM Id to mitigate this security risk.

Steps involved in migrating from Basic Id to IBM Id.

• Customer will have to create a new IBM Id and provide to ACP OPS team.

Link to create IBM ID

• Once the IBM Id is created in the previous step, that should be provided to the ACP OPS team, the ACP team will create tenant which will be linked to this IBM Id like (test, development, production).
  
  
• Changes in “Security” section: - This section will have major and critical changes which the customer will have to make, since it has users and group access configured and certificates associated to the projects.
  
  

• Basic Id existing behavior: - At present customers can create a user with any domain and extension since it not necessary to verify the email associated to user. For example, this any@anydomain.xyz is possible to create today and this user can log in with these credentials and will have privileges assigned to it.

This behaviour is not supported in IBM Id. When creating users in IBM Id tenant, admin have to make sure that user id exists as IBM Id. If admin adds a user id that does not exist as IBM Id then login will fail. When the user clicks on login, he has to select IBM Id (not Basic) and the user will be redirected to IBM Id for authentication. Once authentication passes, the user will be redirected back to the App Connect Professional dashboard.

Note: - when user is created in IBM Id tenant it is assumed that the email id provided is an existing IBM Id and it won’t be validated while creating, it will be validated only while login.

All new user’s id and functional ids that are added should be IBM Id. IBM Id creation page make sure its valid email id to received code. So, it’s not ACP constrain. Its IBM Id constrain. ACP just need a valid IBM Id.

•    Trust Store / Key Store: - The certificates which are associated to the project should be exported and import in the new IBM Id tenant.
  
  

•  All the users in “users” section should be created again with appropriate privileges and similarly create “groups” section.
  Note: - the email id of the user should be valid.

• System configuration properties: - The system configuration properties should be set again in the new IBM Id tenant for the projects to run as they were in Basic Id.

• Notification: - Notification under Logs section have Policies and Email. These will also be configured again in new tenant.

• Secure connectors: - The SC name should be added in IBM Id tenant and the configuration file associated to it would need to be updated in the already installed SC.

•   Connector libraries: - Verify if any connector specific libraries need to be re-uploaded to the new tenant.

Final step: - Once the new tenant is configured with all possible settings as existing tenant. Now projects can be downloaded from the old tenant and uploaded to the new tenant one by one.

• If there are HTTP inbound activities interfaces, then the credentials need to change for invoking these interfaces. The new IBM Id should replace the old credentials.
  
  
• Users will have to edit their client like SFDC and others which are doing HTTP Post call to ACP provided interface. The old credentials should be replaced by the new IBM Id.