Skip to main content

FAQ

How do users obtain an activation code before proceeding with activation?

Users can obtain an activation code by using a Postman collection integrated with API calls. The Postman documentation provides step-by-step instructions on generating the activation code.

What triggers the activation flow, and when should users initiate it?

The activation flow is triggered when a StartResultEvent with ACTIVATION_REQUIRED as sdkState is received in response to the StartEvent. Users should initiate the activation flow in response to this event.

What are the request parameters used in KssIdp Activation, and what information should be provided for clientId and credentials?

The request parameters for KssIdp Activate include clientId, which is provided by the KOBIL-IDP services, and credentials, which include username, password, and activation code.

Can you explain the significance of authentication modes during the KssIdp Activation, and where can users find more information about these modes?

In the KOBIL Shift Lite environment, users can choose between several authentication modes during the KssIdp Activation. More information about these modes is available here.

How does the SDK handle responses to ActivateEvent, and what is the role of SetAuthorisationCodeResultEvent?

As a response to ActivateEvent, the SDK sends a SetAuthorisationCodeResultEvent with appropriate status. This event plays a crucial role in handling the outcome of the activation process.

How does the login flow differ from the activation flow, and what specific events indicate the need for a login?

The login flow is triggered when a StartResultEvent with LOGIN_REQUIRED as sdkState is received. It differs from the activation flow in terms of the required user interaction, as it involves providing a username and password instead of an activation code.

Can you elaborate on the hashing process of user credentials during the login flow? How does the SDK ensure the security of user passwords?

In compliance with BDDK regulations, the SDK ensures a secure hashing process for user credentials during the login flow. This process aligns with the specified requirements to meet regulatory standards, ensuring that passwords are securely stored and transmitted.

Are there specific considerations or best practices when choosing authentication modes during the login process? How do these modes impact the user experience and security?

Authentication modes play a crucial role in the login process. Considerations and best practices should be followed when choosing these modes to balance user experience and security. More information about these modes is available here.

In the context of login failures, how does the SDK handle these situations gracefully while maintaining security? What feedback is provided to users?

In the event of login failures, the SDK gracefully handles the situations, providing clear feedback to users without compromising security. This ensures that users receive informative messages while maintaining the integrity of the login process.

Device Specifications:​

Does your device have secure elements?
On iOS it is more common feature and iPhone 5s or newer devices have Secure Enclave. On Android it is safe to assume that every Samsung high-end model released after the S20 should have a secure elements chip inside.
When configuring the config files, what considerations should developers keep in mind to align with security policies, and are there specific parameters influencing the choice of security policies?

Developers should align configurations of config files with security policies, considering parameters like "mTLS", "mKex" and "useSEKeyForSigningTransactions" to meet security requirements.

Why Android version 6.0 devices are not supported by MC - SDK?

As Android manufacturers deprecate older versions, such as Android 6, these platforms become susceptible to numerous security flaws. It is not feasible to address these vulnerabilities individually as there are many of them.

Application Deployment:​

Is it possible to automatically transfer existing app versions to the Shift environment using a pipeline?

Automatically upgrading app versions is not possible through pipelines; typically, app version upgrades are performed through the respective app stores.

Has the previously selected architecture type during the app version in SSMS been removed?

There is no longer an architecture type selection inside Smart Dashboard. You now need to specify the platform the app will be working on, and it will conform to every architecture.

Is the credential type in KOBIL IDP customized, and has there been a change in the use of Activation Code?

The change to accommodate activation codes in KOBIL IDP is customized. A new credential type, ACTIVATION_CODE, has been added for the same by extending KOBIL IDP's internal credential provider.

Secure Element Configuration:​

How is Secure Element configuration handled on the App side?

Secure Element functionality is only supported by Secure Enclave devices. If mobile devices do not support Secure Enclave, configure the "maverick" of the mc_config file as follows:

  • e.g., in Android and iOS: 
    "maverick": {
       "mTLS": true,
       "mKex": false,
       "useSEKeyForSigningTransactions": false
    }

Else if mobile devices support Secure Enclave, configure the "maverick" of the mc_config file as follows:

  • e.g., in Android and iOS: 
    "maverick": {
       "mTLS": true,
       "mKex": true,
       "useSEKeyForSigningTransactions": true
    }

Environment Setup:​

Can Redis be installed outside Kubernetes/OpenShift?

Yes, Redis can be installed outside Kubernetes/OpenShift.

Is it possible to install Kafka outside Kubernetes/OpenShift?
No, the current version does not support such configuration.
What URLs must be accessible from Kubernetes/OpenShift?
Which tool is used to install the application, and what deployment options are available?

Helm is used to install the application. KOBIL Shift is built upon helm chart packages. There is no single manifest deployment option.