Uses Case: restrict access for time period Uses Case: enforce rules for specific group of users
OGC 07-118r8 User Management Interfaces for EO
46 Copyright © 2010 Open Geospatial Consortium, Inc.
The following table covers implementation-dependant threats.
Type of attack threat Answer countermeasures
SQL injection If a RDBMS is used for user registry, there is a risk of SQL injection
for the authentication operation, i.e. a hacker enters as user id or password, some malicious character string that are interpreted by
SQL engine.
Such risk can be prevented by performing string validation and character escaping on input user id password strings, before SQL
lookup out of scope of the present interface.
LDAP injection If a LDAP registry is used for user registry, there is a risk of LDAP
injection, i.e. a hacker enters as user id or password, some malicious character string that are interpreted by LDAP or JNDI API. See
http:www.blackhat.compresentationsbh-europe-08Alonso- ParadaWhitepaperbh-eu-08-alonso-parada-WP.pdf
Such risk can be prevented by performing string validation and character escaping on input user id password strings, before LDAP
lookup out of scope of the present interface.
10 Authorisation Use Cases non-normative
As explained before, authorisation rules that grant access to Web services shall be evaluated by a dedicated PEP that wraps such services. However, the PEP treatments and the way
access rules are stored and evaluated are not in the scope of the present document. The present section provides non-normative information about this topic.
In order to separate responsibilities, a PEP typically relies on a PDP Policy Decision Point that performs the actual evaluation of access rules based on the request payload i.e. the
SOAP body, on the attributes of the SAML token, if any, present in the SOAP header and on external elements e.g. current time. Each PDP should have a dedicated policy store, where
needed access rules or policies can easily be stored, retrieved and maintained.
The rules used by each PDP should be expressed in a standard syntax: the eXtended Access Control Markup Language XACML is recommended here. XACML see [NR21] is, in
essence, a declarative access control policy language implemented in XML. It is worth mentioning here also GeoXACML see [NR25], which is an extension of XACML for the
declaration and enforcement of geo-specific access restrictions for geographic data.
The following provides use cases and examples of policy rules, with XACML fragments implementing them. More comprehensive examples shall be found in annex E.