Mobile application version management
As organisation you only want approved application versions to be able to communicate with the Token Server. Therefore application version management is an
important feature of the Token Server. Each application version which is published must be configured. When talking about an application version a version of
the application for a specific platform is used. So for example: PaymentApp v1.1 Android
.
An application should prove it is the application version it pretends to be when it communicates with the Token Server for the first time. When this is proved the application will receive credentials which can be used for further communication. Based on these credentials all requests for this application can be correlated to this specific application installation.
In order to create a new application, go to the Configuration
section of the administration console, then App Configuration
and open the Applications
tab.
From the list of applications click on the application identifier in the Identifier
column. At the bottom of the screen the versions for this application can
be managed.
- Configure a new application version
- Remove an existing app version
- Forcing end-users to upgrade
- Prevent new installation usage of the application
Configure a new application version
Click on the Add platform version
button to create a new platform version.
The Version
fields need to be filled with the version identifier. The version identifier is a free format input field. Both numeric and textual input are accepted. It
is advised to use numeric values to see the relation between versions in terms of which is the latest.
The Enabled for new registrations
checkbox indicates that this version of the application is allowed to register itself as a new application installation on
the Token Server. If this option is not checked only applications that already had registered before can keep using the Token Server without upgrading.
The Disabled
checkbox is used to completely disable the usage of a specific version. For example when a version configuration is created for future usage or
the version contains some issue which requires it to be disabled. Or when a version is very old and customers are not allowed to use it anymore.
The application sends a signature to prove that is the version it pretends to be. This signature is set in the Application signature
field. An app developer will
deliver this Application signature as described in the App delivery lifecycle topic. When the application is in
development mode any value can be filled in as an Application signature because this value is ignored in development mode. When tampering detection is enabled the Application signature has to be hexadecimal
formatted and be 32, 48 or 64 characters long. When an Application signature contains a |
, this indicates that multiple architectures are supported. Every architecture requires a different Application signature.
The rules (when tampering protection is enabled) apply on all Application signatures separated by the |
individually. So the following Application signature is not valid:
12345|ABCDEF1234567890ABCDEF1234567890
because the first part does not have the correct size.
To prevent tampering with the application, for example via byte code manipulation, the Tampering protection
checkbox should be checked. With tampering
protection the application has to prove its identity to the Token Server frequently.
For the communication of sensitive information TLS/SSL might not be sufficient. The Payload encryption
feature adds an additional layer of encryption. To use
payload encryption a Onegini Security Proxy installation is required. Enabling Payload encryption
without Onegini Security Proxy does not have any effect.
Push messaging configuration
can be selected from the dropdown list. It only shows the Push messaging configurations for the selected platform. For more
information about it go to the Mobile authentication page.
Remove an existing app version
Via the application version list a trash icon can be found. An app version can only be removed when no application installations are using the application version. An alternative to removing a version is forcing end-users to upgrade.
Forcing end-users to upgrade
There are several reasons why you would like end-users to upgrade their applications. For example:
- Reduce support costs due to less application versions.
- Act on known security vulnerabilities.
- Backwards incompatibility with backend systems.
- Force users to start using the latest features.
In order to force users to upgrade to a newer application version the old application version must be disabled. This can be achieved by editing the old version and
checking the Disabled
checkbox. Users will be prompted to upgrade via the app store when using the disabled application. After upgrading from an
application version which is disabled the user can use the application again without having to register again.
Note: Users might experience bad usability when they are forced to upgrade when users only have a mobile connection available. Forcing a user to upgrade makes the current application version unusable.
Prevent new installation usage of the application
To prevent new application installations of an outdated version the version can be disabled for new registrations. This can be achieved by editing a version
and uncheck the Enabled for new registrations
checkbox. Users will be prompted to upgrade via the app store when using the application for the first time.
Users that already used the application before won't notice any disturbance. After upgrading or downgrading from an application version which is disabled the user
can use the application again without having to register again.