Show TOC

Mapping a Logical Role to a Physical RoleLocate this document in the navigation structure

SAP Mobile Platform includes predefined logical roles, and uses HttpServletRequest.isUserInRole(logicalRole) for its policy enforcement points in the runtime. Physical roles assigned to a user come from your identity management back-end systems. Those physical roles are manually mapped to SAP Mobile Platform logical roles by editing the appropriate role-mapping.xml file.

Context

A common implementation example is using the Directory Service (LDAP/AD) authentication provider in an SAP Mobile Platform security profile, and mapping to the LDAP groups to which a user belongs. Each LDAP group has a physical role attributed to the authenticated user in SAP Mobile Platform.

The CSI then uses the role-mapping configuration to convert the isUserInRole() check to see if the user is granted any of the physical roles defined in the role-mapping for the security profile. Role mapping is particularly important for the Admin security configuration where authorized users must be mapped to the Administrator logical role. Additionally, in other security profiles, it is important to map Impersonator and Notification User roles, depending on your scenario.

The security profiles are persisted in files that are located in <SMP_HOME>\Server\configuration\com.sap.mobile.platform.server.security\CSI. To map a logical role to the appropriate physical role in the underlying security provider in a given security profile, you must manually edit the corresponding <Security_Profile_name>-role-mapping.xml file.

Note

The Management Cockpit always authenticates against the Admin security profile and requires that the user be granted the Administrator role to successfully log into the Management Cockpit.

     
Upon installation, the default authentication provider assigns the smpAdmin user to the Administrator role. To make your configuration production ready, you must add an authentication provider to the Admin security profile that authenticates against your identity management system (such as LDAP for Active Directory). To do this, you must:
  • Determine the physical role names detected by your identity management system; for example, the names of LDAP groups to which the user belongs
  • Select the appropriate logical role in SAP Mobile Platform
Note Be sure to understand your groups of users so you map only the roles intended for the corresponding security profile. Mapping large groups risks including more users than necessary in your security profile. To mitigate this risk, consider using the UserRoleAuthorizer feature to provide improved security by defining a specific user, and not a group, in LDAP. This technique is required for certificate-based authentication.

The following steps describe mapping the Admin role. These same steps apply to any logical role, where you edit the corresponding <role-name>-role-mapping.xml file. To map the Administrator logical role to physical role on your back-end security system, perform the following steps:

Procedure

  1. Navigate to the admin-role-mapping.xml file, which by default appears as:
      <?xml version="1.0" encoding="UTF-8" ?> 
    - <rm:Mappings xmlns:rm="http://www.sybase.com/csi/3.1/mapping">
      - <DefaultMapping>
          <LogicalName>Administrator</LogicalName> 
          <MappedName>Administrator</MappedName> 
        </DefaultMapping>
        <!--  Avatar Deployer Role Mappings  --> 
      - <DefaultMapping>
          <LogicalName>NodeManager.deploycontent</LogicalName> 
          <MappedName>Administrator</MappedName> 
        </DefaultMapping
      - <DefaultMapping>
          <LogicalName>GenerationAndBuild.generationandbuildcontent</LogicalName> 
          <MappedName>Administrator</MappedName> 
        </DefaultMapping>
      - <DefaultMapping>
          <LogicalName>IntegrationOperationServer.read</LogicalName> 
          <MappedName>Administrator</MappedName> 
        </DefaultMapping>
      - <DefaultMapping>
          <LogicalName>Developer</LogicalName> 
          <MappedName>Developer</MappedName> 
        </DefaultMapping>
      - <DefaultMapping>
          <LogicalName>Helpdesk</LogicalName> 
          <MappedName>Helpdesk</MappedName> 
        </DefaultMapping>
      - <DefaultMapping>
          <LogicalName>Notification User</LogicalName> 
          <MappedName>Notification User</MappedName> 
        </DefaultMapping>
      - <DefaultMapping>
          <LogicalName>Impersonator</LogicalName> 
          <MappedName>Impersonator</MappedName> 
        </DefaultMapping>
      </rm:Mappings>
    
    Note Each logical role name is mapped to a physical role of the same name. By default, the Admin security profile assigns the smpAdmin user to the Administrator role.
  2. Edit the file to assign required physical roles to the corresponding logical roles. For example, if you have a physical role of SysAdmin in your LDAP environment, edit the mapping file to assign the mapped name of SysAdmin to the Administrator logical role:
    
          <DefaultMapping>
                <LogicalName>Administrator</LogicalName>
                <MappedName>Administrator</MappedName>
                <MappedName>SysAdmin</MappedName>
          </DefaultMapping>
    
    Note By default, SAP Mobile Platform includes <MappedName>Administrator</MappedName> in this file. If you do not have a physical role or group called Administrator, delete this mapping from the file to avoid unnecessary authorization checks and improve performance.
  3. Save the file changes.
    Note

    In a SAP Mobile Platform cluster, security configurations, including profiles and role mappings, are stored in the database shared by the cluster. Security profiles are configured using the Management Cockpit, and role-mappings are configured manually by editing the corresponding role-mapping.xml file in the file system. Security related items can be maintained or created from any active node in the cluster. Once security configuration changes are made, either manually or using the Management Cockpit, the CSI pushes the security configuration to the shared database, which then propagates the changes to the cluster nodes.