Locked History Actions

iGeoSecurity

iGeoSecurity

1. general description

deegree iGeoSecurity consits of four components:

  1. user and rights management database
  2. WAS/WSS
  3. owsProxy
  4. drm-admin / DRMAccess / AD-LDAP-importer

The first component is 'just' a database schema designed for storing objects that shall be managed be deegree iGeoSecurity. There is no limitation to what kind of objects be managed. You can handle WMS layers or WFS featuretypes as well as books or cars; we call these objects 'securable objects'. Users are a special kind of a 'securable object'. The same is true for user groups and roles. An administrator is a special kind of user and thus a 'securable object' as well. Roles are groupings of rights. E.g.: The rights to dislay a layer and to get info on its features (GetMap and GetFeatureInfo) are usually coupled, so both rights can be grouped into one role. In deegree exists an API for accessing the user and rights management database, so it can be used in any context you like.

The second component is an authentication service that sits upon the deegree user and rights management database. Through this service a user can get a ticket (sessionID) and softcomponents can check if a sessionID is valid and who is the user behind it.

The third component is owsProxy. It is a ServeltFilter that can be used in front of deegree WMS/WFS/CSW or in combination with a simple proxy servlet deegree offers in front of any WMS/WFS/CSW. For a client the service behind an owsProxy still looks like a compliant OGC web service! An owsProxy can check incoming requests against the deegree user and rights management database and deny access to resources if a user is not allowed to. Access can be limited by each parameter being part of a request and by some derived parameters. Access can be limited by spatial and by logical conditions. Examples:

  • User X is not allowed to perform GetMap requests on layer ABC if the spatial resolution (scale) of the requested map is better than 10m or the requested boundingbox is not within 5,52,21,83.

  • User X is not allowed to perform GetFeature-requests on featureType {http://www.deegree.org/app}:TestFT.

  • User X is not allowed to perform GetMap requests with boundingBoxes that have a distance of more than 2km from river XYZ.

The owsProxy also filters results to requests. If a user is not allowed to perform any operation on a layer or featuretype this layer/featuretype will not occur in capabilities returned for a GetCapabilities request. It is also possible to avoid returning feature or metadatarecords by defining user specific filter conditions, so a user may perform a GetFeature request against featureType {http://www.deegree.org/app}:TestFT but just feature intersecting polygon ABC will be returned.

The owsProxy knows four mechanisms for identifying:

  1. user/password (must be part of the request)
  2. sessionID (must be part of the request; see WAS/WSS)
  3. IP-address (IP address can be handled as normal user, so you can assign rights to it)
  4. network identification (this may require some additional installation like Microsoft IIS)

You are free to write your own identification mechanism and plug it into owsProxy - you just need to implement the base interface.

The fourth component are three programmes set up on deegree user and rights management database. drm-admin is a web application offering a GUI that enables managing users and rights for ~90% of all use cases. DRMAccess is a commandline program that offeres methods for managing the complete functionality of the user and rights management database. AD-Importer and LDAP-Importer are two programmes that syncronised users and groups (least just for AD) from Active Directory and LDAP with deegree user and rights management database.

2. owsProxy

The newer version of deegree's owsProxy is represented by the class ConfigurableOWSProxyServletFilter. An older version (simply named OWSProxyServletFilter) is still available, but it is deprecated.

deegree's owsProxy is able to evaluate incoming requests and outgoing response and check them against policies that may be defined global (same for each user) or user specific. If a request violates a condition defined in the policies an exception will be thrown. The same is true if a user can not be authenticated against the user and rights management (if configured to recognize individual users). Evaluating response is slightly diffenrent. In this case owsProxy does not throw exceptions (except for GetRecordById and GetRepositoryItem response) but it changes the reponse by removing all objects that are not explictly allowed for a user.

This points to a major design concept of deegree owsProxy: It implements a pessimistic rights concept. This means one has to explicitly grant rights to a user, an object and the operation to perform on it.

owsProxy is configured by the servlet containers deployment descriptor and by a configuration file (as convenience it is named authentication.xml). The deployment descriptor defines which OWS shall be protected and which policy is assigend to an OWS protection. Also it will be defined which authentication methods shall be used in which order to authenticate a user. Here is an example for a deployment descriptor as used with apache tomcat (for a detailed description of each parameter please have a look at the documentation):

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
    <filter>
        <filter-name>OWSProxy</filter-name>
        <filter-class>org.deegree.security.owsproxy.ConfigurableOWSProxyServletFilter</filter-class>
        <init-param>
            <param-name>WFS:POLICY</param-name>
            <param-value>WEB-INF/conf/security/wfspolicy.xml</param-value>
        </init-param>
        <init-param>
            <param-name>WMS:POLICY</param-name>
            <param-value>WEB-INF/conf/security/wmspolicy.xml</param-value>
        </init-param>
        <init-param>
            <param-name>CSW:POLICY</param-name>
            <param-value>WEB-INF/conf/security/cswpolicy.xml</param-value>
        </init-param>
        <init-param>
            <param-name>PROXYURL</param-name>
            <param-value>http://10.19.1.131/owsproxy/proxy</param-value>
        </init-param>
        <init-param>
            <param-name>AuthenticationSettings</param-name>
            <param-value>/WEB-INF/conf/security/authentication.xml</param-value>
        </init-param>
        <init-param>
            <param-name>ALTREQUESTPAGE</param-name>
            <param-value>/altrequestpage.jsp</param-value>
        </init-param>
        <init-param>
            <param-name>ALTRESPONSEPAGE</param-name>
            <param-value>/altresponsepage.jsp</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>OWSProxy</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    <servlet>
        <servlet-name>services</servlet-name>
        <servlet-class>org.deegree.enterprise.servlet.OGCServletController</servlet-class>
        <init-param>
            <param-name>services</param-name>
            <param-value>WMS,WFS,CSW</param-value>
        </init-param>
        <init-param>
            <param-name>WMS.handler</param-name>
            <param-value>org.deegree.enterprise.servlet.WMSHandler</param-value>
        </init-param>
        <init-param>
            <param-name>WMS.config</param-name>
            <param-value>/WEB-INF/conf/wms/wms_capabilities.xml</param-value>
        </init-param>
        <init-param>
            <param-name>WFS.handler</param-name>
            <param-value>org.deegree.enterprise.servlet.WFSHandler</param-value>
        </init-param>
        <init-param>
            <param-name>WFS.config</param-name>
            <param-value>/WEB-INF/conf/wfs/wfs_capabilities.xml</param-value>
        </init-param>
        <init-param>
            <param-name>CSW.handler</param-name>
            <param-value>org.deegree.enterprise.servlet.CSWHandler</param-value>
        </init-param>
        <init-param>
            <param-name>CSW.config</param-name>
            <param-value>/WEB-INF/conf/csw/csw_capabilities.xml</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>services</servlet-name>
        <url-pattern>/services</url-pattern>
    </servlet-mapping>
</web-app>

An important new feature compared with the deprecated version of owsProxy is the capability of configurable authentication methods. This configuration is done by referencing an XML document containing information on which authentication method(s) to use and in which order they shall be performed. 'Order' of performing means that owsProxy will start to authenticate a user with the first method defined in authentication configuration. If a user can be authenticated, everything is fine and owsProxy goes on with validating the incomming request. If a user cannot be authenticated using the first defined method, owsProxy tries authentication with the second defined method and so on. Only if no method succeeds in authenticating a user the complete process fails and an exception will be thrown. Here is an example for an authentication configuration:

<?xml version="1.0" encoding="UTF-8"?>
<Authentications>
    <Method name="user:password">
        <class>org.deegree.security.UserPasswordAuthentication</class>
    </Method>
    <Method name="sessionID">
        <class>org.deegree.security.WASAuthentication</class>
        <init-param>
            <name>WAS</name>
            <value>http://localhost:8081/was/was</value>
        </init-param>
    </Method>
    <Method name="UserPrincipal">
        <class>org.deegree.security.UserPrincipalAuthentication</class>
    </Method>
    <Method name="IP-Address">
        <class>org.deegree.security.IPAddressAuthentication</class>
        <init-param>
            <name>pattern</name>
            <value>127.0.0.*,localhost,19.1.10.21</value>
        </init-param>
    </Method>
</Authentications>

Two things are important to recognize:

  1. Each method description contains information about the Java class that performs the authentication. So it is possible to define/use other methods than those available in deegree.
  2. Each pattern defined for method 'IP-Address' can be registered as a user in deegree user and rights management system (drm-admin / DRMAccess). So it is possible to treat IP segments as normal users.

3. drm

For drm-admin, read a short introduction: WebClients#drm-admin.

...TBD...


CategoryDeegree2