Mobile Component Descriptor  |  User Management

User-dependent Data Filtering

Introduction

MI Client tightly integrates into NetWeaver's authorization concept by

Mobile applications are thus enabled to to differentiate between users with respect to the scope of functionality and data access according to their roles.

This chapter explains the overall architecture and API for tying into this concept.

The data filtering service only allows applications to define what users should be allowed to do what and see what data. Nonetheless, there is no protection against bad-will attacks, if malevolent users have access to the device's file system (as is the case with all common PDA operating systems). Such user can theoretically access the persisted data directly or manipulate the authorization data to in such a way that the application grants them access.

This is why SAP chose to use the term 'user-dependent data filtering' instead of the term 'authorization concept'.

SAP suggests to protect the locally stored authorizations and data by by an external mechanism against unauthorized manipulation, like for example enforcing users to use device login.

Please read the definitions for authorization and authorization object in the glossary.

 

Authorization Check within Mobile Applications

The com.sap.ip.me.api.security package within the MI client API provides functionality to check an authorization for the current user. The analogy to the ABAP statement authority-check is kept as far as it is necessary to allow server side maintenance with in the standard authorization tools of the SAP NetWeaver. The result of the check is a yes or no answer. The reaction on the result of the check is in the responsibility of the application. MI Client itself also uses this concept for doing authority checks itself (likThis does not exclude the option that some of the checks are performed by the MI runtime (e.g. the authorization to run an application)!

The API is in line with the IUser concept of the User Management Engine (UME) in SAP Enterprise Portal. While not the full UME functionality is required by MI Client and mobile applications, at least a semantical similarity is required for the authorization check functionality. This is why the com.sap.ip.me.api.user.User interface has a number of empty methods - they are only required in the respective UME interface.

The application needs to declare used authorization objects in the MCD of the application, otherwise the users authorizations will not be replicated to the client.

Please check the Javadoc for com.sap.ip.me.api.security.Permission for coding examples of the user-dependent data filtering service.

Server-side Administration of Authorizations for Mobile Users

The authorizations are maintained on the server with standard tools of SAPNetWeaver (SAP authorization concept). There is absolutely no differentiation between authorization objects used for backend ABAP functionality and MI client authorization during the maintenance. During each synchronization only the authorizations that are needed on the MI client are transferred to the device. Server-side changes are updated at each synchronization.

When a user logs on to the MI Client before the initial synchronization he doesn’t see any applica-tions and there is no need to have any authorizations yet. After the initial synchronization applications are downloaded and all authorizations required for that user and the newly downloaded applications. At each subsequent synchronizations the completeness of the authorizations on the client is checked again. Therefore additional authorizations will be provided automatically, if new applications are deployed.
The decision on the needed authorizations is based on the users on the device and the applications. On the server a user has a long list of authorizations for different authorization objects. The authorizations are grouped by different concepts like profiles, composite profiles, roles. For each mobile application the authorization objects used are specified in the MCD of the application (transaction MI_MCD, tab Environment, Dependency name AUTHOBJECT). Only those authorizations are transferred to the device that belong to the users on the device and belong to authorization objects referred to by the MCDs of the applications installed on the device.

It is not possible to maintain authorizations locally

 

Data volume and performance

The total number of authorizations of a user might be large. Because only those authorizations that are explicitely specified by the application's MCD are downloaded to the device, the data volume for authorizations are still kept small.

The performance of the authorization check mechanism scales with the number of authorizations on the client. The number of authorization can be limited to a reasonable amount by an application (MCD) specific filtering.
A second aspect is the replication of authorizations to the client. To optimize the performance in this area the cached list of authorizations that is also used within the ABAP authority check is used.