about how to control access to spatial data in your Web project (i)

Wednesday, JUNE

　Recently, I've been working on the issue of how to implement rights management for spatial data (published on GeoServer) in my Webgis project. Although we have not been able to find a perfect solution so far, but through these days of learning and access to information, the idea of how much progress, so recorded, do a simple summary.

Security modules in the 1-geoserver

　　GeoServer is a GIS application server that enables users to share and edit geospatial data based on the Java EE Foundation. --from GeoServer Official Introduction.

In fact, the essence of GeoServer is a Java-based implementation of the Web project project, I used in the project GeoServer is a war package version, directly copy it to the /%tomcathome%/webapp/ path, Launch Tomcat,geoserver is deployed in Tomcat just like your own Web project. When GeoServer is deployed, you can/geoserver into the GeoServer Control Panel via http://localhost:yourport (your port number).

In the left-hand menu bar of Control Panel, you can easily find the security settings for GeoServer. Next I will briefly introduce the concept of permission assignment for resources already published on GeoServer, and to avoid this blog being an experimental report, I will try to minimize the description of the actual operating section, mainly introducing the structure and principle of the security module.

　　1-1 characters

In GeoServer, the role is made up of three parts: Name/parent role/key-value Pairs, where the parent role "father" takes advantage of the concept of inheritance so that each role can have a parent element. A child role can inherit all the permissions of a parent role, such as a role a,a_a is a child role, and all permissions owned by a can be inherited by A_a , but a Do not necessarily have all the permissions of the a_a, it can be understood that the two are a progressive relationship, the parent element can access the resources of certain permissions, the child elements of a higher degree of privacy, on the basis of the permissions of the parent element, can have more resources access to power.

The implementation of any system security module is based on a sub-role authorization mode. GeoServer is no exception, in GeoServer , role service is mainly implemented by the following three aspects:

-Character table

-Authorization mechanism

- geoserver mapping between system roles and application roles (including administrators, role groupings)

Both the role table and the authorization mechanism are like normal security modules, and you can set up new roles and assign them to different users through the visualizations in the control Panel. The association between the roles in GeoServer and the roles you set is a critical part of the GeoServer role service, because only if you have a new role mapped with a system role mapping can you get permission to manage the data in the GeoServer.

In geoserver, role mappings are configured primarily in the following two ways:

- XML ( default mode)

- jdbc uses jdbcto assign permissions to user tables in the database (recommended)

In general, you only need to select the Users/groups/roles column in the menu bar on the GeoServer Control Panel and set it in the appropriate location to create new, modify, and activate role service, as you need to visually view the structure of the XML configuration file. You can see the related role assignments you set up by accessing/%geoserverhome%/data/security/role/{yourroleservicename} .

PS: Under this path, there are altogether the following three files:

-Config: map the roles of the local role and the system to each other

- roles.xml: Set Role type, assign user role information

-Roles.xsd: define The implementation mode of the service

　　1-2 User authentication Authentication

The previous section basically revolves around the role, the user, the user group and so on the concept to GeoServer 's authorization way carries on the brief introduction. But a complete user rights subsystem should have two key elements at the same time: authorization (Authorization) and authentication, so let's take a look at the user authentication in GeoServer ( Authentication) mode.

This is part of the configuration interface in the Authentication-add new authentication filter in the left-hand menu bar, where we can see that GeoServer offers a number of authentication methods, including the Java EE, form form, HTTP Header validation and so on, where Geoservery is the default scheme with Form form authentication, as shown in the process (source from http://docs.geoserver.org/stable/en/user/security/ usergrouprole/interaction.html):

We can clearly understand the general process of user authentication geoserver, mainly rely on the User/group service and role service two services for authorization and authentication, In the GeoServer platform, the Authority control and management of GeoServer project are realized.

1-3 Certification Chain

The first 1-2 section briefly introduces the basic concept and process of user authentication, in fact, in the process of GeoServer's permission function realization, there is a very important concept--the certification chain, which is the key to understand the whole security authentication mechanism.

　　The so-called certification chain,authentication chain, which is a processing request and apply for the corresponding certification mechanism, wherein the authentication mechanism mainly includes the following :

-Username/password: Look up user information in the external user database

-Browser Cookies: Find the previous authentication record in the browser cache cookies

-LDAP: authentication based on LDAP database

-Anonymous: No certification required

　　Multilevel permission authentication mechanism can be activated in one run of GeoServer.

　　

　　

　　　From what we can see, before the request enters the Dispatchservlet, GeoServer first requests the authentication chain The filtering, requests each through the authentication chain each mechanism, if any one authentication mechanism can successfully match the request, then returns the request to the normal request processing path, Distribute to the appropriate handler, or return error message 401.

In fact, the authentication chain process consists of two chains:

A filter chain (filter chain): Whether the request requires authentication → do not need to go directly into the process request process

↓

Need

↓

A provider chain (rule chain): Request matches that permission authentication

　　

　　The Ps:filter chain filter chain exists in the sense that:

- Collection of user certificates from request

-Ability to handle issues such as logout (logging out) and Remember Me browser cache settings

-Manage Session

-Help rule chain to accept a number of requests without authentication, reduce the request load

It is important to note that different filter chain can handle different kinds of requests, so the administrator can set the corresponding filter chain for different users, it is important to note that if there are multiple filter chains matching the request, only the first filter chain that meets the requirements is taken.

　　　 1-4 OWS && REST Services

What is discussed earlier is the change in the state of the user role after the role is authenticated, and the result of user role authentication affects the permissions assigned to the user to access resources and operate in the app. The next step is to introduce the authentication process based on the OWS (opengis_webservice) and REST service, which does not have a concept of session, so the authorization system requires the client to provide a certificate for each request. However, if the session exists on the server side, the session can be used for authentication.

　　1-4-1 certification chain for OWS service

　　

• Session: Processing Integration session
• Basic Auth: Extract permission certificate from HTTP header (Username && passwords)
• Anonymous: Handling Anonymous access to "tourists"

　　1-4-2 WMS's Certification chain

Specific process Description:

Ⅰgetcapabilities Request

Ⅱgetmap request for a secured layer

For example, Basic Auth is triggered to determine whether to login, if it is still anonymous login (Anonymous), then return to the user HTTP 401 code, jump to the user login interface, if the completion of the login, will enter the rule chain, to provide access to the user resources and operations.

Ⅲservice

The GeoServer control of the granularity of permissions reaches the Service level, enabling the user's operations (OWS and Rest) to be locked and controlled, with two services:ows (WFS,WMS) and restful Service in the geoserver.

-oWS Service

Path:%geoserverhome%/data/security/services.properties

E.g:wfs. Transaction = Role_wfs_write

Wfs. Getfeature = Role_wfs_read

-Rest Services

Path:%geoserverhome%/data/security/rest.properties

e.g:<uripattern>; [<method1>,<method2> ...] =<role1>,<role2>

/**; Get,post,put,delete=role_administrator

The Get method has the Read-only property, which is suitable for general user access, while the Post,put,delete method is suitable for roles with certain permissions.

　　

Assign the permissions of the resource and action methods to each role through the properties files stored under their respective paths.

It is important to note that, in the official document of GeoServer, the privilege control of service granularity is not used in conjunction with the permission control of layer granularity, that is, the two controls are relatively independent, and you cannot specify that the request and operation permissions of a particular OWS service in a particular layer belong to a role.

Well, here's the basic concept and implementation of the GeoServer security module, and I'm going to strive to integrate spring security and geoserver security within this week, The following section describes how to implement rights-managed content in your own web app to call spatial data published in GeoServer.

　　

about how to control access to spatial data in your Web project (i)