Mobile Component Descriptor | User Management
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. |
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.
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 |
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.