Show TOC

Mapping Logical Roles to Physical Roles in XML FilesLocate this document in the navigation structure

Administrators can define SAP Mobile Platform logical roles. Users' physical roles are derived from your identity management back-end systems. You can map logical roles to physical roles either using Management Cockpit or by editing an XML file.

Context

Note

SAP recommends that you use Management Cockpit, instead of this procedure, to map roles—see Mapping Logical Roles to Physical Roles.

This topic describes how to map logical roles to physical roles by editing the appropriate <profile-name>-role-mapping.xml file.

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.

To enforce runtime policy, SAP Mobile Platform uses HttpServletRequest.isUserInRole(logicalRole). The CSI uses the role-mapping configuration to run isUserInRole 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. In other security profiles, it is important to map Impersonator and Notification User roles, depending on your scenario.

Security profiles are persisted in files that are located in the <SMP_HOME>\Server\configuration\com.sap.mobile.platform.server.security\CSI directory. To map a logical role to the appropriate physical role for a security profile, edit the corresponding <profile-name>-role-mapping.xml file.

Note

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

Upon installation, the default authentication provider grants the Administrator role to the smpAdmin user. To make your system production ready, 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, and
  • Select the appropriate logical role in SAP Mobile Platform.
Note Verify that you understand your group of users so you map only the roles required for the corresponding security profile. If you map large groups, you risk 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.

To map a logical role to physical roles on your back-end security system, edit the <profile-name>-role-mapping.xml file. The following steps describe how to map the Administrator logical role:

Note

If you edit a role-mapping file with an editor that inserts byte order mark (BOM) characters, such as XML Notepad, errors occur when the SAP Mobile Platform XML parser processes the role mapping file, and you cannot log in to Management Cockpit. To avoid this issue, either configure the editor to not store BOM characters when saving XML files, or use a text editor that does not insert BOM characters.

Procedure

  1. Open the admin-role-mapping.xml file, which by default contains:
      <?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 is mapped to a physical role with the same name.
  2. Map the required physical roles to the corresponding logical roles. For example, if you have a physical role called SysAdmin in your LDAP environment, map SysAdmin to the Administrator logical role:
    <DefaultMapping>
       <LogicalName>Administrator</LogicalName>
       <MappedName>Administrator</MappedName> 
       <MappedName>SysAdmin</MappedName>
    </DefaultMapping>
    
    Note By default, the admin-role-mapping.xml file includes <MappedName>Administrator<MappedName>. If your system does not include a physical role or group called Administrator, delete this mapping from the file to improve performance by avoiding unnecessary authorization checks.
  3. Save the file changes.
    Note

    In a server cluster, security configurations, including profiles and role mappings, are stored in the database shared by the cluster. You can configure security profiles using Management Cockpit. You can create and maintain security-related items on any active node in the cluster. After you update a security configuration, the CSI pushes the new configuration to the shared database, which then propagates the changes to all the cluster nodes.