Role services¶

A role service provides the following information for roles:

List of roles
Calculation of role assignments for a given user
Mapping of a role to the system role ROLE_ADMINISTRATOR
Mapping of a role to the system role ROLE_GROUP_ADMIN

When a user/group service loads information about a user or a group, it delegates to the role service to determine which roles should be assigned to the user or group. Unlike User/group services, only one role service is active at any given time.

By default, GeoServer supports two types of role services:

XML—(Default) role service persisted as XML
JDBC—Role service persisted in a database via JDBC

Mapping roles to system roles¶

To assign the system role ROLE_ADMINISTRATOR to a user or to a group, a new role with a different name must be created and mapped to the ROLE_ADMINISTRATOR role. The same holds true for the system role ROLE_GROUP_ADMIN. The mapping is stored in the service’s config.xml file.

<roleService>
  <id>471ed59f:13915c479bc:-7ffc</id>
  <name>default</name>
  <className>org.geoserver.security.xml.XMLRoleService</className>
  <fileName>roles.xml</fileName>
  <checkInterval>10000</checkInterval>
  <validating>true</validating>
  <adminRoleName>ADMIN</adminRoleName>
  <groupAdminRoleName>GROUP_ADMIN</groupAdminRoleName>
</roleService>

In this example, a user or a group assigned to the role ADMIN is also assigned to the system role ROLE_ADMINISTRATOR. The same holds true for GROUP_ADMIN and ROLE_GROUP_ADMIN.

XML role service¶

The XML role service persists the role database in an XML file. This is the default role service for GeoServer. This service represents the user database as XML, and corresponds to this XML schema.

Note

The XML role file, roles.xml, is located in the GeoServer data directory, security/role/<name>/roles.xml, where <name> is the name of the role service.

The service is configured to map the local role ADMIN to the system role ROLE_ADMINISTRATOR. Additionally, GROUP_ADMIN is mapped to ROLE_GROUP_ADMIN. The mapping is stored the config.xml file of each role service.

The following provides an illustration of the roles.xml that ships with the default GeoServer configuration:

<roleRegistry version="1.0" xmlns="http://www.geoserver.org/security/roles">
  <roleList>
    <role id="ADMIN"/>
    <role id="GROUP_ADMIN"/>
  </roleList>
  <userList>
    <userRoles username="admin">
      <roleRef roleID="ADMIN"/>
    </userRoles>
  </userList>
  <groupList/>
</roleRegistry>

This configuration contains two roles named ADMIN and GROUP_ADMIN. The role ADMIN is assigned to the admin user. Since the ADMIN role is mapped to the system role ROLE_ADMINISTRATOR, the role calculation assigns both roles to the admin user.

For further information, please refer to configuring a role service in the Web administration interface.

J2EE role service¶

The J2EE role service parses roles from the WEB-INF/web.xml file. As a consequence, this service is a read only role service. Roles are extracted from the following XML elements:

`<security-role>`¶

<security-role>
   <role-name>role1</role-name>
</security-role>
<security-role>
   <role-name>role2</role-name>
</security-role>
<security-role>
   <role-name>employee</role-name>
</security-role>

Roles retrieved:

role1
role2
employee

`<security-constraint>`¶

 <security-constraint>
    <web-resource-collection>
        <web-resource-name>Protected Area</web-resource-name>
        <url-pattern>/jsp/security/protected/*</url-pattern>
        <http-method>PUT</http-method>
        <http-method>DELETE</http-method>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>role1</role-name>
        <role-name>employee</role-name>
    </auth-constraint>
</security-constraint>

Roles retrieved:

role1
employee

`<security-role-ref>`¶

<security-role-ref>
    <role-name>MGR</role-name>
    <!-- role name used in code -->
    <role-link>employee</role-link>
  </security-role-ref>

Roles retrieved:

MGR

JDBC role service¶

The JDBC role service persists the role database via JDBC, managing the role information in multiple tables. The role database schema is as follows:

Table: roles¶
Field	Type	Null	Key
name	varchar(64)	NO	PRI
parent	varchar(64)	YES

Table: role_props¶
Field	Type	Null	Key
rolename	varchar(64)	NO	PRI
propname	varchar(64)	NO	PRI
propvalue	varchar(2048)	YES

Table: user_roles¶
Field	Type	Null	Key
username	varchar(128)	NO	PRI
rolename	varchar(64)	NO	PRI

Table: group_roles¶
Field	Type	Null	Key
groupname	varchar(128)	NO	PRI
rolename	varchar(64)	NO	PRI

The roles table is the primary table and contains the list of roles. Roles in GeoServer support inheritance, so a role may optionally have a link to a parent role. The role_props table maps additional properties to a role. (See the section on Roles for more details.) The user_roles table maps users to the roles they are assigned. Similarly, the group_roles table maps which groups have been assigned to which roles.

The default GeoServer security configuration is:

Table: roles¶
name	parent
Empty	Empty

Table: role_props¶
rolename	propname	propvalue
Empty	Empty	Empty

Table: user_roles¶
username	rolename
Empty	Empty

Table: group_roles¶
groupname	rolename
Empty	Empty

For further information, please refer to configuring a role service in the Web administration interface.

LDAP role service¶

The LDAP role service is a read only role service that maps groups from an LDAP repository to GeoServer roles.

Groups are extracted from a specific LDAP node, configured as the Groups search base. A role is mapped for every matching group. The role will have a name that is built taking the Group common name (cn attribute), transformed to upper case and with a ROLE_ prefix applied.

It is possible to filter extracted groups using an All groups filter (defaults to cn=* that basically extracts all nodes from the configured base). It is also possible to configure the filter for users to roles membership (defaults to member={0}).

A specific group can be assigned to the ROLE_ADMINISTRATOR and/or the ROLE_GROUP_ADMIN administrative roles.

Groups extraction can be done anonymously or using a given username/password if the LDAP repository requires it.

An example of configuration file (config.xml) for this type of role service is the following:

<org.geoserver.security.ldap.LDAPRoleServiceConfig>
  <id>-36dfbd50:1424687f3e0:-8000</id>
  <name>ldapacme</name>
  <className>org.geoserver.security.ldap.LDAPRoleService</className>
  <serverURL>ldap://127.0.0.1:10389/dc=acme,dc=org</serverURL>
  <groupSearchBase>ou=groups</groupSearchBase>
  <groupSearchFilter>member=uid={0},ou=people,dc=acme,dc=org</groupSearchFilter>
  <useTLS>false</useTLS>
  <bindBeforeGroupSearch>true</bindBeforeGroupSearch>
  <adminGroup>ROLE_ADMIN</adminGroup>
  <groupAdminGroup>ROLE_ADMIN</groupAdminGroup>
  <user>uid=bill,ou=people,dc=acme,dc=org</user>
  <password>hello</password>
  <allGroupsSearchFilter>cn=*</allGroupsSearchFilter>
</org.geoserver.security.ldap.LDAPRoleServiceConfig>

For further information, please refer to configuring a role service in the Web administration interface.

REST role service¶

The REST role service is a read only role service that maps groups and associated users to roles from a remote REST web service.

The REST service must support JSON encoding.

Here is a listing of significant methods provided by the REST Role Service (based on the LDAP role service, which similarly has to make network calls to work):

Table: roles¶
Method	Mandatory
getUserNamesForRole(roleName)	N (implemented in LDAP, but I don’t see actual users of this method besides a utility method that nobody uses)
getRolesForUser(user)	Y
getRolesForGroup(group)	N
getRoles()	Y (used by the UI)
getParentRole(role)	N
getAdminRole()	Y
getGroupAdminRole()	Y
getRoleCount()	Y (does not seem to be used much, we can trivially implement it from getRoles()

REST APIs¶

The following is an example of the REST API the role service may handle. The JSON and remote endpoints may differ; this is configurable via UI, allowing the REST role service to connect to a generic REST Service

From the above we could have the following REST API to talk to

../api/roles

Returns the full list of roles (no paging required, we assume it’s small). Example response:

{"groups":["r1","r2","r3"]}

../api/adminrole

Returns the role of the administrator (yes, just one, it’s strange…):

{"adminRole":["root"]}

../api/users/<user>

Returns the list of roles for a particular user. Example response:

{"users": [{"user":"u1", "groups":["r1","r2"]}]}

Configurable API¶

The GeoServerRoleService talking to a remote service provides the following config parameters:

Base URL for the remote service
Configurable URLs for the various calls
JSON paths to the properties that contain the list of roles, and the one admin role

The above can be configured via the Web administration interface. The figure below shows the REST role service options configured to be compatible with the sample APIs above:

REST based role service configuration panel¶

Previous: Roles

Next: Role source and role calculation

Role services¶

Mapping roles to system roles¶

XML role service¶

J2EE role service¶

`<security-role>`¶

`<security-constraint>`¶

`<security-role-ref>`¶

JDBC role service¶

LDAP role service¶

REST role service¶

REST APIs¶

Configurable API¶

Table Of Contents

Continue Reading

This Page

Known GeoServer issues

Role services¶

Mapping roles to system roles¶

XML role service¶

J2EE role service¶

<security-role>¶

<security-constraint>¶

<security-role-ref>¶

JDBC role service¶

LDAP role service¶

REST role service¶

REST APIs¶

Configurable API¶

Table Of Contents

Continue Reading

This Page

Known GeoServer issues

`<security-role>`¶

`<security-constraint>`¶

`<security-role-ref>`¶