Securing map.apps

Mapping apps have been part of the web ecosystem for a long time now. While simple, generic applications enjoy great popularity amongst general users, professional users are also part of this trend, as organisations increasingly see the value of publishing their own data holdings into the Web. Once data and services are accessible via the Internet, the question about access protection and authorization is often raised, and rightly so. Luckily, there is a solution available to provide peace of mind when publishing potentially sensitive spatial data via the Internet. con terra offers a product, security.manager, that helps manage access constraints with respect to services and data in service-oriented architectures. It enables access control for authorized users, and provides extensive functionality that enables the implementation of fine-grained authorization concepts. The combination of map.apps and security.manager allows secure applications to be deployed, where both functionality and content can be finely tailored according to the rights of the authenticated user. The three use cases below provide an overview of how map.apps and security.manager can work together to fulfill some common scenarios.

1. The innovative (and fictitious) company “Mapterprise” provides many different map services. Operational data about different topics are managed centrally and sold to external customers. These customers are supposed to access only those services they have paid for. This scenario can be easily implemented by combining map.apps with sdi.suite security.manager. map.apps is able to consume service that are protected with the security.manager. Technically, a cookie-based Single Signe On (SSO) mechanism is used to realize this. By an integrated login dialog in map.apps, the user is authenticated against security.manager and can access protected services according to the authorization policies defined and stored by security.manager. Therefore, a Domain SSO Cookie is created for the user. The cookie is not just visible to the host machine that writes the cookie, but for the whole domain that the host machine belongs to. If map.apps accesses a service that is protected by security.manager, this cookie is sent, analyzed and if matching the according right sets, access is granted.
2. The cable network operator „Cable Inc.“ runs various web-based information portals that allow customers to get information about network breakdowns or planned expansion of the cable network. Beyond that, business clients should be able to enter data about new network breakdowns on their own to allow immediate work on removal of the defects. This requirement is also easily implementable with a combination of map.apps and security.manager. One of the core design principles of map.apps is the fast and easy creation of light-weight and focused applications (“apps”) that focus on one specific primary context. Access to those apps can be restricted to certain user roles by the security.manager. With the embedded login dialog, a user can be logged on to security.manager as already described in scenario one. The app that the user wants to access is recognizable in the URL that the user has started. This URL parameter is analyzed by security.manager and handed over to a „Policy Decision Point“ (PDP) (integrated part of security.manager). The PDP has access to a database that contains different policy sets and analyzes if the user is allowed to access the desired resource (in this case a specific app) and will grant or deny access on the basis of these rules.
3. „Apps4Geo“, another fictitious company, that develops small applications in the GIS context, is active on the market with extensions for existing GIS solutions. The company offers various license models to its customers including „Pay-per-Use“. To keep costs and efforts manageable, certain tools and components should be available only for selected users.

   Again, this scenario can be realized by an interaction of map.apps and security.manager. It is possible to grant access to certain components for specified user roles only. Depending on the user role that is assigned to a user, the same app might have more or less tools than available to another user.

   Technically, this is solved by using security.manager’s “tag-library”. The app.json file, that contains the app configuration, is embedded in a .jsp file, that can be extended by tags. One of the tags supported by security.manager is “IsInRole” for example. But you can also initiate more complex queries. The following configuration sample illustrates the principle: "selection", If the user has assigned the role “Administrator”, selection tools will be shown. In all other cases this bundle will not be loaded.

All scenarios described on this page can be implemented by simple configuration, no programming work is needed. The support for combining map.apps and security.manager is already delivered in both products!