security.manager - Enterprise Edition

This section refers to the connections of map.apps with security.manager Enterprise Edition, solely.

By connecting to security.manager, the following possibilities exist:

  • Assignment of roles for the use of the map.apps Manager

  • Protection of apps

  • Protection of tools

  • Use of secured services without logging on again (Single Sign-On)

Create connection between map.apps and security.manager

Operation of map.apps and security.manager on the same host

The following parameters must be added or changed in the global configuration.

security.mode=ONLY_AUTHN

# security.manager adminstration service location
security.administration.url=https://<yourserver>/administration

# Key Store Location.
# This is the path to the keystore (`.keystore` file) shared by security.manager and map.apps
security.keystore.location=C:/data/conterra/.keystore

If further settings for the keystore are changed in security.manager (for example password), these must also be added in the map.apps configuration.

Operation of map.apps and security.manager on different hosts

If security.manager is installed on a different server than map.apps, the keystore file must be copied to the map.apps server.

In addition to the settings described in the previous section, the following parameter must be added or changed in security.manager configuration (whereas example.com is the name of the host where map.apps is installed).

security.allowed.hostnames=example.com

For map.apps, it may be required to set the cors.request.trustedServers property as well.

# comma separated list of servers like:
cors.request.trustedServers=https://securitymanager.example.com:8443

Using self-registration and password recovery

In order to use the self-registration and/or password recovery options of security.manager, map.apps can be pointed to the security.manager login page (instead of using the integrated login dialog).

Change the following property:

security.login.service.url=https://yourserver/administration/account/login

Use of the map.apps Manager

To be able to use the map.apps Manager in a SSO scenario with security.manager, it is mandatory to assign the role of a map.apps administrator to the user that should be able to use the map.apps Manager application. To achieve this, it is necessary to create the role maAdmin in security.manager and assign it to the dedicated user.

Use of protected services

Services protected by security.manager are configured similar to unprotected services in an app. Instead of the original URL of the service, the SSO endpoint provided by security.manager must be used.

When the user logs in, the domain cookie is added to each request sent by the browser. The SSO endpoint of security.manager applies all rights defined in the rights management for the respective user (for example displaying certain layers of a service).

After the user has logged out, the domain cookie is destroyed and access to the protected services is no longer possible.

Service definition of a protected service
{
    "id": "secured_countries",
    "type": "AGS_DYNAMIC",
    "url": "https://www.example.com/wss/service/myAGS/sso/MyData/MapServer",
    "layers": [
        {
            "id": "3",
            "title": "Countries"
        }
    ]
}

Providing User Specific Bundles and Widgets

The following only applies to applications stored in the file system, without using map.apps Manager.

Take the following steps to provide role based bundles and widgets (can be used for tools as well).

At first, configure an app in map.apps Manager and export it. Afterwards the extracted app has to be placed in the following folder: {map.apps dir}\js\apps\YourApp. It might be necessary to create the subfolder apps/ manually. The app.json file has to be renamed to app.jsp.

You can use a security.manager library to filter app configuration files. This technique uses the security.manager tag library and requires to define a JSP file (app.jsp) instead of a JSON file (app.json). Despite a special header, the content definition of the files is similar. When the file is requested from the server, it is transformed into a JSON file without the additional header. Within the JSP file, special tags can be used to filter certain content, based on the user’s role.

Example
 <s:isInRole role="myRole">"selection"</s:isInRole>

In this example the selection-string is only added to the file if the current user has the role myRole. This tag can be used at any position in the file, for example to exclude bundles in the allowedBundles section or to exclude certain tools from a toolset definition.

Sample of an app.jsp file
 <%@ page contentType="application/json; charset=UTF-8" pageEncoding="UTF-8" language="java" session="false" isThreadSafe="true" isELIgnored="true"%><%@ taglib uri="https://www.conterra.de/security/tags" prefix="s"%>{
   "load": {
     "allowedBundles": [
       "system",
       "map",
       "themes",
       "templates",
       "templatelayout",
       "windowmanager",
       "coordinatetransformer",
       "result-ui",
       "contentviewer",
       <s:isInRole role="sM_Administrator">"selection",</s:isInRole>
       "infoviewer",
       "toolset",
       "toolrules",
       "authentication"
     ]
   },
   "bundles": {
     ...
   }
 }

To transform the content of the JSP file to a JSON file, it is necessary to create a reference to the file in the global configuration and to add it to the list of protectedAnonymousResources.

 ...
 security.application.jspMappings=.......,/js/apps/{YourApp}/app.json
 security.application.protectedAnonymousResources=/js/sample/,/js/sample/*.html,**/appauthorization/app.json,**/{YourApp}/app.json
 ...